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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:17 EST