[lkml]   [1998]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 'disposable' dirty pages [was: Out Of Memory in v. 2.1]
    In message <>, 
    NAR Ingo writes:
    | On Thu, 8 Oct 1998, Chris Wedgwood wrote:
    | > > Hmm, I'm wondering. I haev this application, it allocates 10
    | > > blocks each 1 megs in size. Then I free() 5 of those blocks, but
    | > > the program is still eating 10 megs of memory.
    | > > Is this right?
    | >
    | > Using the `normal' libc malloc - yes.
    | > There are other mallocs out there which try to return the memory to
    | > the kernel though.
    | There is a _reason_ why malloc doesnt return pages immediately. It's
    | performance. There is a reason why X caches pixmaps. It's performance. So

    Sort of. Performance hits occur because the application has to identify
    pages that can be returned; it can't compact the heap to free up pages, so
    it's relatively rare for pages to become candidates for release to the OS
    unless the program allocates and free large chunks of memory. If it only
    allocates and frees small chunks, the cost of scanning the free block list
    coalescing blocks and searching for pages that can be released is

    Ultimately, the problem is that C/C++-style memory management is not
    conducive to this. A program which uses garbage collection *and* manages
    its memory specifically for garbage collection would see less of a
    performance hit and would be able to release pages to the OS more often.

    The extended malloc() in System V (-lmalloc), which supports releasing
    memory if the program makes a specific mallopt() call to enable it, is
    actually faster than the stock one... this demonstrates that performance
    doesn't *have* to go downhill. But the program using it still must manage
    its memory sensibly for it to work... and because it can't control where it
    allocates memory, it can't do reasonable heap compacting.

    brandon s. allbery [os/2][linux][solaris][japh]
    system administrator [WAY too many hats]
    electrical and computer engineering KF8NH
    carnegie mellon university

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.020 / U:8.716 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site