> 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/