9

I was reading a little bit about malloc and found the following in the malloc's man page:

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). Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).

So basically starting from the threshold MMAP_THRESHOLD malloc start using mmap.

  1. Is there any reason to switch to mmap for large chunks?
  2. Could this hit the process execution performance?
  3. Does the mmap system call force a context switch?
Guy Avraham
  • 3,482
  • 3
  • 38
  • 50
rkachach
  • 16,517
  • 6
  • 42
  • 66
  • 1
    (1) Yes; (2) theoretically yes, but in practice this improves performance in most cases, which is the reason for (1); (3) every system call does. – n. m. could be an AI Oct 14 '15 at 14:56
  • @n.m. Not all the system calls require a context switch. Take a look to the the following thread http://stackoverflow.com/questions/9238326/system-call-and-context-switch – rkachach Oct 15 '15 at 06:51
  • Apparently it's a difference in terminology. You probably want to know if mmap is blocking or not. The call itself may not be blocking but it hardly matters. Your process will get a page fault and be forced into a context switch anyway. – n. m. could be an AI Oct 15 '15 at 08:28

1 Answers1

15

(1) Pages acquired via anonymous mmap can be released via munmap, which is what glibc is doing. So for small allocations, free returns memory to your process's heap (but retains them in the process's memory); for large allocations, free returns memory to the system as a whole.

(2) Pages acquired via anonymous mmap are not actually allocated until you access them the first time. At that point, the kernel has to zero them to avoid leaking information between processes. So, yes, the pages acquired by mmap are slower to access the first time than those recycled through your process's heap. Whether you will notice the difference depends on your application.

The cost of not using mmap is that freed memory is still tied up by your process and unavailable to other processes on the system. So this is ultimately a trade-off.

(3) It does not "force" a context switch and is, I believe, unlikely to cause one. mmap does not actually allocate the pages; it just manipulates the page map for your process. That should typically be a non-blocking operation. (Although I admit I am not 100% sure about this.)

Nemo
  • 70,042
  • 10
  • 116
  • 153
  • thanks for the answer. I'm still investigating on the point #3 just to see if the mmap force a context switch or not. – rkachach Oct 15 '15 at 06:51
  • @rkachach Do you have any update on the finding? I am also trying to learn whether mmap systemcall results in context switch – talekeDskobeDa Apr 10 '19 at 08:53
  • @talekeDskobeDa There's no guarantee that it will, and there's no guarantee that it won't, either. You mustn't rely on either behavior. – zwol Aug 28 '22 at 14:28