[lkml]   [2002]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] move slab pages to the lru, for 2.5.27

On Sun, 21 Jul 2002, Ed Tomlinson wrote:

> Well not quite random. It prunes the oldest entries.

Yes, you're right, I was speaking sloppily.

I meant "random" in the sense that "those pruned entries don't correspond
to the page I'm scanning right now in refill_inactive_zone". Establishing
that connection seems simultaneously very interesting and confusing. :)

> What I tried to do here was keep the rate of aging in sync with the VM.

I think it works darn well too! But maybe a page-centric freeing system
would do that too. In your patch, you distinguish between:

- aging prunable slab pages by "counting" the slab pages
to determine the rate of pruning, and using the caches' internal
lru order to determine the actual entries that get pruned
- aging non-prunable slabs with page->age.

Can we unify them and just use page->age (or, in the case of stock 2.5.27,
do it in the VM's LRU order)? That is, if you encounter a cold slab page
in scanning the active list, try to prune just *that* page's slab
resources. If it manages to free the slab, free the page. Otherwise,
try again next time we visit the page.

> Thats a question I have asked myself too. What could be done is, scan
> the entries in the slab encountered,

I think *that's* the part I'm having difficulty envisioning. If
cachep->pruner, then I might find myself in dcache.c (for example)
living in a pruner callback that no longer remembers "my" slab page.
Seems like we need a "dentry_lookup" method that returns a list of
[di]cache objects living in a specified slab (page). Then feed that
list to a modified prune_[di]cache and see if that frees the slab.

Not the current "prune 'N' old entries from the cache, and I don't care
where they live in memory". We're coming in instead and saying "I _know_
this page is old, so try to free its entries". This is, I suppose, saying
that we want to throw out (or at least ignore) the caches' internal LRU
aging methods and use the VM's LRU order (2.5.27), or page->age (2.5.27
plus full rmap). Uh oh. This is getting scary. And maybe wrong. :)

So, that list-returning method has me befuddled. And maybe we don't
really want to do any of this. Which is why I asked. :)

> Looking at the Intermezzo dcache code, I think you made the right choise.
> I do not think this needs a pruner method.

Whew! :)


Craig Kulesa
Steward Obs.
Univ. of Arizona

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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