glibc malloc()은 작은 블록 메모리 할당에 mmap()을 사용합니까?

나는 Linux에서 glibc의 malloc()이 매우 큰 메모리 블록에는 mmap()을 사용하고 작은 할당에는 brk()를 사용한다는 것을 배웠습니다. 그러나 테스트 프로그램을 이용하여 이론을 실험해 보니, 그렇지 않은 것 같았다.

먼저 코드에서 "for" 루프를 사용하여 Option1==TRUE 조건의 배열로 구현된 큰 메모리 덩어리(80MB)를 할당했으며 각 할당은 페이지 크기의 배수였습니다. Option2==TRUE이면 메모리 블록이 완전히 해제됩니다. Option1과 Option2는 프로세스가 실행 중인 명령줄에서 설정할 수 있습니다.

관찰: 옵션 1이 충족되면 프로세스의 RSS 값이 80MB 증가합니다. 그런 다음 Option2를 TRUE로 설정한 다음(Option1이 충족되지 않은 동안) RSS 값에서 거의 같은 양의 메모리를 뺍니다(OS로 돌아가기). 여태까지는 그런대로 잘됐다.

그 후 "for" 루프를 수정하여 할당했습니다.둘대용량 메모리(각각 80MB)는 다음과 같이 구현됩니다.조각그리고블록 1옵션 1로. 각 루프에서 두 배열의 동일한 인덱스에 동일한 양의 메모리가 할당되며 각 할당은 다음과 같습니다.더 작은한 페이지 이상. 메모리 블록은조각Option2==TRUE일 때 완전히 해제됩니다. 그리고 메모리 블록블록 1Option3==TRUE일 때 완전히 해제됩니다.

관찰: Option1==TRUE일 때 내 프로세스의 RSS 값은 160MB 증가했고 Option2==TRUE 이후에는 값이 동일하게 유지되었습니다. 또한 Option3==TRUE 이후에도 변경되지 않습니다. Valgrind Massif 도구를 사용하여 메모리 사용량을 확인한 결과 "for" 루프에 있는 두 개의 malloc() 함수가 약 160MB의 페이지를 매핑했다고 보고했습니다.

할당된 작은 메모리 블록이 향후 할당에 사용될 수 있도록 프로세스에 유지된다는 것을 이해할 수 있습니다. 하지만 이러한 작은 할당은 mmap() 대신 brk()로 구현하면 안 되나요? valgrind가 정확한 보고를 제공하지 않기 때문입니까, 아니면 mmap()을 사용하여 malloc()을 구현하는 다른 경우가 있습니까?

두 번째 테스트의 코드는 아래에 복사되어 있습니다.

        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;
                }
            }
        }
......