Re: 2.4.16 memory badness (fixed?)

From: Leigh Orf (
Date: Mon Dec 10 2001 - 10:49:24 EST

Rik van Riel wrote:

| On Mon, 10 Dec 2001, Ken Brownfield wrote:
| > What about moving the calls to shrink_[di]cache_memory()
| > after the nr_pages check after the call to kmem_cache_reap?
| > Or perhaps keep it at the beginning, but only call it
| > after priority has gone a number of notches down from
| >
| > Something like that seems like the only obvious way to
| > balance how soon these caches are flushed without over- or
| > under-kill.
| So obvious that it's been re-introduced 3 times now even
| though it broke each time. ;)

And in fact, after furthur playing around with the "fixed" version
(moving shrink_[id]cache_memory to the top of vmscan.c::shrink_caches)
I find that I still will get ENOMEM after updatedb occasionally. Less
often than before, but it still happens.

| The only way to get stuff balanced somewhat is to call
| the shrink functions unconditionally. It's not optimally
| balanced, but at least the cache will stay reasonably small
| while still being able to grow under load.

I just can't understand why the kernel wouldn't tag application memory
as being more important tan buff/cache and free up some of that stuff
when an application calls for it. I mean, it won't even use the gobs of
swap I have. That just seems to be a plain ol' bug to me.

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

This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:17 EST