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/