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
and
- 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! :)
Comments?
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 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 : Tue Jul 23 2002 - 22:00:36 EST