What are the differences between "brk()" and "mmap()"?

This is a discussion on What are the differences between "brk()" and "mmap()"? within the Linux Programming forums, part of the Platform Specific Boards category; I am confused by the differences between "brk()" and "mmap()". My understanding is that both are used by malloc() to ...

  1. #1
    Registered User
    Join Date
    Apr 2007
    Posts
    284

    What are the differences between "brk()" and "mmap()"?

    I am confused by the differences between "brk()" and "mmap()". My understanding is that both are used by malloc() to increase the boundary ot heap.

    Then why there are 2 different ways?


    http://lwn.net/images/ns/kernel/mmap1.png

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by meili100 View Post
    I am confused by the differences between "brk()" and "mmap()". My understanding is that both are used by malloc() to increase the boundary ot heap.
    brk() is a traditional way of allocating memory in UNIX -- it just expands the data area by a given amount. mmap() allows you to allocate independent regions of memory without being restricted to a single contiguous chunk of virtual address space.

    malloc() uses the data space for "small" allocations and mmap() for "big" ones, for a number of reasons, including reducing memory fragmentation. It's just an implementation detail you shouldn't have to worry about.

  3. #3
    Registered User
    Join Date
    Apr 2007
    Posts
    284
    Thank you. I can understand brk(), but what if brk() reaches the boundary of the top of a heap (4G memory)?
    Also, how does mmap() allocate memory by mapping? What is the source of the mapped memory? My friend told me that mmap() maps kernal memory to user, but I really doubt him. Is he right?

    Quote Originally Posted by brewbuck View Post
    brk() is a traditional way of allocating memory in UNIX -- it just expands the data area by a given amount. mmap() allows you to allocate independent regions of memory without being restricted to a single contiguous chunk of virtual address space.

    malloc() uses the data space for "small" allocations and mmap() for "big" ones, for a number of reasons, including reducing memory fragmentation. It's just an implementation detail you shouldn't have to worry about.

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,744
    Moved to Linux Programming since that is the most related forum.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by meili100 View Post
    Thank you. I can understand brk(), but what if brk() reaches the boundary of the top of a heap (4G memory)?
    Also, how does mmap() allocate memory by mapping? What is the source of the mapped memory? My friend told me that mmap() maps kernal memory to user, but I really doubt him. Is he right?
    Both brk() and mmap() cause pages to be mapped into the process's address space. mmap() can be used to map pages of a file into memory, but it can also be used only to map pages, i.e., allocate memory. brk() is just a specific interface to the VM subsystem which maps pages at a specific location (top of heap). mmap() on the other hand lets you map any page (mostly) anywhere you want.

    brk() could be implemented with mmap(), but not vice versa.

    As for where the pages come from, that's up to the kernel. The process can decide which virtual address it wants mapped -- the kernel is responsible for allocating a physical page and mapping it where the process has requested.

  6. #6
    Registered User
    Join Date
    Apr 2007
    Posts
    284
    Why don't we use mmap() in the first place? We know that brk() has a disadvantage that: if the block at the top of heap is not freed, the heap size can not be reduced, even if the top block is only ONE BYTE.

    mmap() is better than brk(). So why don't we use mmap()?

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    mmap() is no better unless you really want to cater for the rather special case that you want to reduce the heap when it's got most of it's memory freed but a small section at the top end of the heap is occupied. The brk() model is perfectly fine for most purposes, as the heap will normally (in typical applications) grow to a certain size, and then either fluctuate a little bit up and down from that size, or grow and then shrink again. In the normal case for grow and shrink, it's mainly "newest allocations" being deallocated.

    Also, if there are large "holes" in the heap, those areas are good candidates for swapping out to disk, as they will not be touched. So whilst it's taking up VIRTUAL memory space, it's not going to cause much of a problem in the physical memory (assuming there's a squeeze in the first place of course).

    Oh, and by the way, memory allocated via brk() is most likely not committed until it's being written to, so if you allocate a large chunk of memoyr (using malloc() or close relatives), not all that memory will be used in physical memory until it's been "used" (read or written).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by meili100 View Post
    Why don't we use mmap() in the first place? We know that brk() has a disadvantage that: if the block at the top of heap is not freed, the heap size can not be reduced, even if the top block is only ONE BYTE.

    mmap() is better than brk(). So why don't we use mmap()?
    As matsp said, things get swapped out and don't cause a problem anyway. And if you really wanted to release memory inside the heap, nothing is stopping you from munmap()'ing it (aside from probably confusing the hell out of malloc()).

    brk() is just an older, traditional way of obtaining more pages from the OS. I don't really think either one is "better" than the other.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21