lkml.org 
[lkml]   [2001]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.16 memory badness (fixed?)
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. ;)

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.

Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/

http://www.surriel.com/ http://distro.conectiva.com/

-
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:14    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog