lkml.org 
[lkml]   [2002]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Possible Idea with filesystem buffering.
Let's try a non-reiserfs sub-cache example.  Suppose you have a cache of 
objects that are smaller than a page. These might be dcache entries,
these might be struct inodes, these might be all sorts of things in the
kernel.

Suppose that there is absolutely no correlation in access between the
objects that are on the same page. Suppose that this subcache has
methods for freeing however many of them it wants to free, and it can
squeeze them together into fewer pages whenever it wants to. Suppose it
can track accesses to the objects, and it could age them also, if we
wrote the code to do it.

If we age with page granularity as you ask us to, we are doing
fundamentally the wrong thing. Aging with page granularity means that
we keep in the cache every object that happens to land on the same page
with a frequently accessed object even if those objects are never
accessed again ever.

Another wrong way: Ok, so suppose we have methods for shrinking the
cache ala the old 2.2 dcache shrinking code. Suppose we invoke those
whenever the cache gets "too large", or the other caches are failing to
free pages because things have gotten SO pathologically inbalanced that
they have nothing they can free. This is also bad. It results in
unbalanced caches, and makes our VM maintainer think that subcaches are
inherently bad.

If we don't have a master VM pushing proportionally to their size on all
subcaches, and telling them how many pages worth of aging to apply, we
either have unused objects staying in memory because they happen to land
on a page with a frequently used object, or we have unbalanced caches
that know what to free but not how much to free.

We need a master VM that says how much aging pressure to apply, and
subcaches that respond to that. We need a VM that doesn't just
delegate, but delegates skillfully enough that the subcaches know what
they need to know to act on it.

Hans


Rik van Riel wrote:

>On Tue, 22 Jan 2002, Hans Reiser wrote:
>
>>Rik van Riel wrote:
>>
>>>On Tue, 22 Jan 2002, Chris Mason wrote:
>>>
>
>>>>The FS doesn't know how long a page has been dirty, or how often it
>>>>gets used,
>>>>
>>>In an efficient system, the FS will never get to know this, either.
>>>
>>I don't understand this statement. If dereferencing a vfs op for
>>every page aging is too expensive, then ask it to age more than one
>>page at a time. Or do I miss your meaning?
>>
>
>Please repeat after me:
>
> "THE FS DOES NOT SEE THE MMU ACCESSED BITS"
>
We can't borrow whatever pair of glasses the master VM is using?

>
>
>Also, if a piece of data is in the page cache, it is accessed
>without calling the filesystem code.
>
>
>This means the filesystem doesn't know how often pages are or
>are not used, hence it cannot make the decisions the VM make.
>
>Or do you want to have your own ReiserVM and ReiserPageCache ?
>
>regards,
>
>Rik
>



-
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/

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