[lkml]   [2006]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/5] [PATCH,RFC] vfs: per-superblock unused dentries list (2nd version)
    On Thu, Jun 01, Andrew Morton wrote:

    > > Discussed in this thread:
    > >
    > >
    > >
    > > Short summary of the problem: due to SHRINK_BATCH resolution, a proportional
    > > reclaim based on "count" across all superblocks will not shrink anything on
    > > lists 2 orders of magnitude smaller than the longest list as tmp will evaluate
    > > as zero. Hence to prevent small unused lists from never being reclaimed and
    > > pinning memory until >90% of the dentry cache has been reclaimed we need to
    > > turn them over slowly. However, if we turn them over too quickly, the dentry
    > > cache does no caching for small filesystems.
    > >
    > > This is not a problem a single global unused list has...
    > Reasonable. Whatever we do needs to be fully communicated in the comment
    > text please.

    Yes, you are right. As I expected that this isn't the final patch I was a
    little bit too lazy. Will do that for the next version.

    > > > In particular, `jiffies' has near-to-zero correlation with the rate of
    > > > creation and reclaim of these objects, so it looks highly inappropriate
    > > > that it's in there. If anything can be used to measure "time" in this code
    > > > it is the number of scanned entries, not jiffies.

    Ouch! Totally missed that. The measurement should be kind of round-based

    > Don't do a divide?
    > sb->s_scan_count += count;
    > ...
    > tmp = sb->s_dentry_stat.nr_unused /
    > (global_dentry_stat.nr_unused / sb->s_scan_count + 1);
    > if (tmp) {
    > sb->s_scan_count -= <can't be bothered doing the arith ;)>;
    > prune_dcache_sb(sb, tmp);
    > }
    > That could go weird on us if there are sudden swings in
    > sb->s_dentry_stat.nr_unused or global_dentry_stat.nr_unused, but
    > appropriate boundary checking should fix that?

    if (tmp) {
    sb->s_scan_count -= count;
    sb->s_scan_count -= sb->s_scan_count ? min(sb->s_scan_count, count/2) : 0;
    prune_dcache_sb(sb, tmp);

    if (!sb->s_dentry_stat.nr_unused)
    sb->s_scan_count = 0;

    In a normal situations, s_scan_count should be zero (add count and subtract it
    s_scan_count is increasing when we don't prune anything from that
    superblock. If we finally reach the point where the s_scan_count is that high
    that we actually prune some dentries, we slowly (count/2) decrease the
    s_scan_count level again.
    If the superblock doesn't have any unused dentries we reset the s_scan_count to

    So s_scan_count is some kind of badness counter. I hope that this will still
    be good enough for you, David.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-02 17:36    [W:0.177 / U:5.728 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site