lkml.org 
[lkml]   [2001]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.4.16 memory badness (fixed?)
Date

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/

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.111 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site