mmap() will be called by malloc()?

In the man page of malloc, there(NOTES section) is a paragraph as follows:

Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). Prior to Linux 4.7 allocations performed using mmap(2) were unaffected by the RLIMIT_DATA resource limit; since Linux 4.7, this limit is also enforced for allocations performed using mmap(2).

So when you apply for more than MMAP_THRESHOLD of space, malloc() will call mmap().

Someone asked three

Questions

Why call mmap() when apply for large space?

Is there some difference between mmap and malloc?

Will mmap cause a context switching?

Answers

Anonymous pages applied by mmap will be freed by munmap. glibc does this kind of works. As for small space, free will release it to the process's heap. So it will still belongs to the process. But munmap will release the space to the os.

mmap won't allocate pages immediately. They will be allocated the first time they are accessed, when kernel must erase them to zero, intending to avoid leakage of information between processes.

It won't cause context switching when called. But it will eventually cause one. Specifically, mmap is a non-blocking system call. When you mmap a file on disk to memory, mmap just create a map and not allocate pages immediately.