On Thu, Jun 01, Andrew Morton wrote:
> > Discussed in this thread:
> >
> > http://marc.theaimsgroup.com/?l=linux-fsdevel&m=114890371801114&w=2
> >
> > 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
instead.
> 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
again).
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
zero.
So s_scan_count is some kind of badness counter. I hope that this will still
be good enough for you, David.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
