glibc malloc（）は小さなブロックメモリ割り当てにmmap（）を使用しますか？

私はLinuxでglibcのmalloc（）が非常に大きなメモリブロックにはmmap（）を使用し、小さな割り当てにはbrk（）を使用することを学びました。しかし、テストプログラムを用いて理論を実験してみると、そうでなかったようだった。

まず、コード内の「for」ループを使用して、Option1 == TRUE条件の配列として実装された大きなメモリチャンク（80 MB）を割り当て、各割り当てはページサイズの倍数でした。 Option2==TRUEの場合、メモリブロックは完全に解放されます。 Option1とOption2は、プロセスが実行されているコマンドラインで設定できます。

観察：オプション1が満たされると、プロセスのRSS値が80MB増加します。次に、Option2をTRUEに設定し（Option1が満たされていない間）、RSS値からほぼ同量のメモリを減算します（OSに戻る）。今まではそんなに良くなった。

その後、「for」ループを修正して割り当てました。二つ大容量メモリ（それぞれ80 MB）は、次のように実装されています。彫刻そしてブロック1オプション1に。各ループでは、2つの配列の同じインデックスに同じ量のメモリが割り当てられ、各割り当ては次のようになります。小さい1ページ以上。メモリブロックは彫刻Option2==TRUEの場合、完全に解放されます。そしてメモリブロックブロック1Option3==TRUEの場合、完全に解放されます。

観察：Option1==TRUEの場合、私のプロセスのRSS値は160MB増加し、Option2==TRUE以降は同じ値を維持しました。また、Option3==TRUE 以降も変更されません。 Valgrind Massifツールを使用してメモリ使用量を確認したところ、「for」ループ内の2つのmalloc（）関数が約160 MBのページをマッピングしたことを報告しました。

割り当てられた小さなメモリブロックは、将来の割り当てに使用できるようにプロセスに保持されることがわかります。しかし、これらの小さな割り当てはmmap（）の代わりにbrk（）として実装するべきではありませんか？ valgrindが正確なレポートを提供していないためですか、それともmmap（）を使用してmalloc（）を実装する他のケースはありますか？

2番目のテストのコードは以下にコピーされています。

        char *chunk[200000];
        char *chunk1[200000];
        int i = 0;
        int j,k;
......
        if (<Option1 == TRUE>) {
            if (i < 100) {
                for (k=0; k<2000; k++) {
                chunk[i*2000+k] = (char *)malloc(400);
                chunk1[i*2000+k] = (char *)malloc(400);
                memset (chunk[i*2000+k], 0, 400);
                memset (chunk1[i*2000+k], 0, 400);
                }
            }
        }
        if (<Option2 == TRUE>) {
            for (j = 0; j < 200000; j++) {
                if (chunk[j] != NULL) {
                    free(chunk[j]);
                    chunk[j] = NULL;
                }
            }
        }
        if (<Option3 == TRUE>) {
            for (j = 0; j < 200000; j++) {
                if (chunk1[j] != NULL) {
                    free(chunk1[j]);
                    chunk1[j] = NULL;
                }
            }
        }
......