Andreas Gruenbacher wrote: > On Sunday 18 July 2010 08:36:59 Wang Sheng-Hui wrote: >> I regenerated the patch. Please check it. > > The logic for calculating how many objects to free is still wrong: > mb_cache_shrink_fn returns the number of entries scaled by > sysctl_vfs_cache_pressure / 100. It should also scale nr_to_scan by the > inverse of that. The sysctl_vfs_cache_pressure == 0 case (never scale) may > require special attention. I don't think that's right: vfs_cache_pressure ------------------ Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. 0 means "never reclaim," it doesn't mean "never scale." As for nr_to_scan, after the first call, the shrinker has a scaled version of the total count, so the requested nr_to_scan on the next call is already scaled based on that. I think the logic in the mbcache shrinker is fine. -Eric > See dcache_shrinker() in fs/dcache.c. > > Thanks, > Andreas -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
