lkml.org 
[lkml]   [2002]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.5.33-mm1
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/

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