Messages in this thread | | | From | Leigh Orf <> | Subject | Re: 2.4.16 memory badness (fixed?) | Date | Mon, 10 Dec 2001 10:49:24 -0500 |
| |
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/
| |