Ed Tomlinson wrote:
>
> On September 3, 2002 09:13 pm, Andrew Morton wrote:
>
> > ext3_inode_cache 959 2430 448 264 270 1
> >
> > That's 264 pages in use, 270 total. If there's a persistent gap between
> > these then there is a problem - could well be that slablru is not locating
> > the pages which were liberated by the pruning sufficiently quickly.
>
> Sufficiently quickly is a relative thing.
Those pages are useless! It's silly having slab hanging onto them
while we go and reclaim useful pagecache instead.
I *really* think we need to throw away those pages instantly.
The only possible reason for hanging onto them is because they're
cache-warm. And we need a global-scope cpu-local hot pages queue
anyway.
And once we have that, slab _must_ release its warm pages into it.
It's counterproductive for slab to hang onto warm pages when, say,
a pagefault needs one.
> It could also be that by the time the
> pages are reclaimed another <n> have been cleaned. IMO its no worst than
> have freeable pages on lru from any other source. If we get close to oom
> we will call kmem_cache_reap, otherwise we let the lru find the pages.
As I say, by not releasing those (useless to slab) pages, we're causing
other (useful) stuff to be reclaimed.
-
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 Sep 07 2002 - 22:00:20 EST