Messages in this thread | | | Subject | Re: generic aging layer on top of slab allocator? (was Re: PATCH to pre-patch-2.1.45: clean_inode needs to reset i_writecount) | From | (Kevin Buhr) | Date | 10 Jul 1997 19:40:03 -0500 |
| |
Linus Torvalds <torvalds@transmeta.com> writes: > > (you can just consider the current behaviour as > _extremely_ aggressive caching ;)
Hey, maybe we need a new config variable:
CONFIG_I_HAVE_512_GIGS_OF_RAM_BUT_DISKS_BUILT_IN_THE_1940S
> I certainly agree that it might be something interesting to look into. At > the same time I'm a bit nervous about trying to be too generic - in many > cases we can know what kinds of allocation patterns certain objects have, > and maybe do a better job by having a specialized garbage-collector that > has innate knowledge of what it is working with.
Actually, in retrospect, what I was thinking of breaks down into two distinct schemes: one, a generic cache aging toolkit that sounds like what Thomas is working on; and two, some sort of clean mechanism for hooking a custom aging function (written with or without the generic aging toolkit) into the allocator, as an alternative to adding function calls to the loop in "do_try_to_free_page".
Without this second part, we sometimes end up doing aging at "funny times" (i.e., aging from some arbitrary function that we think/hope will get called on a regular basis), when we should usually be doing aging when we actually need memory for something.
Anyway, I think I'll wait for your dentry aging code and try to use it as a starting point for a "proof of concept".
Thanks!
Kevin <buhr@stat.wisc.edu>
| |