Re: 'disposable' dirty pages [was: Out Of Memory in v. 2.1]

Brandon S. Allbery KF8NH (allbery@kf8nh.apk.net)
Thu, 08 Oct 1998 17:31:44 -0300


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/