Rik van Riel wrote:
>On Wed, 23 Jan 2002, Hans Reiser wrote:
>
>>Yes, it should get twice as much pressure, but that does not mean it
>>should free twice as many pages, it means it should age twice as many
>>pages, and then the accesses will un-age them.
>>
>>Make more sense now?
>>
>
>So basically you are saying that each filesystem should
>implement the code to age all pages equally and react
>equally to memory pressure ...
>
>... essentially duplicating what the current VM already
>does!
>
>regads,
>
>Rik
>
If the object appropriate for the subcache is either larger (reiser4
slums), or smaller (have to reread that code to remember whether
dentries can reasonably be coded to be squeezed over to other pages, I
think so, if yes then they are an example of smaller, maybe someone can
say something on this) than a page, then you ought to age objects with a
granularity other than that of a page. You can express the aging in
units of pages (and the subcache can convert the units), but the aging
should be applied in units of the object being cached.
Just to confuse things, there are middle ground solutions as well. For
instance, reiser4 slums are variable size, and can even have maximums if
we want it. If we are lazy coders (and we might be), we could even
choose to track aging at page granularity, and be just like the generic
VM code, except for the final flush moment when we will consider
flushing 64 nodes to disk to count as 64 agings that our cache yielded
up as its fair share. With regards to that last sentence, I need more
time to think about whether that is really reasonably optimal to do and
simpler to code.
Consider an analogy with reiser4 plugins. One of my constant battles is
that my programmers want to take all the code that they think most
plugins will have to do, and force all plugin authors to do it that way
by not making the mostly common code part of the generic plugin
templates. The right way to do it is to create generic templates, let
the plugin authors add their couple of function calls that are unique to
their plugin to the generic template code, and get them to use the
generic template for reasons of convenience not compulsion. I am asking
you to create a cache plugin architecture for VM. It will be cool,
people will use it for all sorts of weird and useful optimizations of
obscure but important to someone caches (maybe even dcache if nothing
prevents relocating dcache entries, wish I could remember), trust me.:)
It is probably more important to caches other than ReiserFS that there
be this kind of architecture (we could survive the reduction in
optimality from flushing more than our fair share, it wouldn't kill us,
but I like to ask for the right design on principle, and I think that
for other caches it really will matter. It is also possible that some
future ReiserFS I don't yet imagine will more significantly benefit from
such a right design.)
Ok, so it seems we are it seems much less far apart now than we were
previously.:)
I remain curious about what dinner cooked by you using fresh Brazilian
ingredients tastes like. The tantalizing thought still lurks in the
back of my mind where you planted it.:) I MUST generate a business
requirement for going to Brazil.....:-)
Hans
-
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 : Wed Jan 23 2002 - 21:00:59 EST