lkml.org 
[lkml]   [1997]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 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
Date
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>

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