Oliver Xymoron wrote:
>
> On Tue, 29 Jan 2002, Andrew Morton wrote:
>
> > Andreas Dilger wrote:
> > >
> > > But if it is unused and not recently referenced, there is little benefit
> > > in keeping it around, is there?
> >
> > In all of this, please remember that all caches are not of
> > equal value-per-byte. A single page contains 32 dentries,
> > and can thus save up to 32 disk seeks. It's potentially
> > a *lot* more valuable than a (single-seek) pagecache page.
>
> Or it might equally well be 32 contiguous directory entries that you
> scanned over to get to the file you wanted.
The `scanned over' entries will be retained in the pagecache,
not in the dentry cache.
> If it's 32 hot items, as a
> page it's going to be aged significantly less than one equally hot
> pagecache page, so I don't think we need to worry about that too much.
Sure they're LRU at present and we could use the referenced bit
in their backing page in the future.
But what we do *not* want to do is to reclaim memory "fairly" from
all caches. The value of a cached page should be measured in terms
of the number of seeks required to repopulate it. That's all.
Andrea's as-yet-unmerged VM patch is much more aggressive about
shrinking the inode and dentry caches. From reading the code, I
have a bad feeling that these caches will shrivel to zilch as soon
as we come under a bit of memory pressure. If so, this could
represent significant imbalance. But this is speculation - I
have not yet tested for this, nor looked at the code closely, and
I probably shan't until it's put up for merging.
-
-
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 : Thu Jan 31 2002 - 21:01:13 EST