lkml.org 
[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]
    Date
    From
    In message <Pine.LNX.3.96.981008135455.25055A-100000@chiara.csoma.elte.hu>, 
    MOL
    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
    +--->8

    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
    prohibitive.

    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] allbery@kf8nh.apk.net
    system administrator [WAY too many hats] allbery@ece.cmu.edu
    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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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