Re: 2.4.16 memory badness (fixed?)

[Leigh Orf]

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
|   > DEF_PRIORITY?
|   >
|   > 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