On Thursday, February 19, 2015 2:03 AM, Michal Hocko <mhocko@xxxxxxx> wrote: >> So do you think is it worth to work on something to give pressure similar >> to vm.vfs_cache_pressure to vfs inode & dentry cache? >> >> I am looking for an effect to let the kernel more aggressively reclaim >> memory from Buffers, > more aggressively than what? Anonymous memory, other types of caches? > To be honest I do not see why we should treat buffers any different from > any other cache. So far it is not clear what might be the issue you are > seeing but I would suspect that too many buffers is not the primary one. > It is hard to say anything more without any specific numbers, though. to get Buffers more aggresively, or ealier reclaimed than lazy on demand. Suppose if someone can do a similar sysctl (say vm.vfs_buffers_pressure, or reuse vm.vfs_cache_presssure), do you think is that worth to do and useful? I think what makes sense to vm.vfs_cache_presssure would also make sense to controll Buffers, right? So far I see people adjust vm.vfs_cache_pressure for various purposes; from default 100 they set it to 50 for more conservatively reclaim memory from cache, or set to a larger value (like 10000) to reclaim the Cached memory earlier, or more aggresively, for Build farms, or in any scenarios that files are all temporary and accessed only in a short time; If those temporary files are finally removed, the Cached memory can be reclaimed, but some cases they may be never removed, For file backup applications, they can do madvise MADV_DONTNEED, but for other applications unaware of MADV_DONTNEED, the kernel may never that Cached memory is not used anymore, keep them for long time, and reclaimed on demand; To reclaim early also has a benefit to save time of reclaim on demand; when in future application really need memory; I'm not sure if any applications are sensitive on time of allocation,, > By reading fs/super.c:prune_super I've also realized taht, which is the > only place referening sysctl_vfs_cache_pressure, > that block_devices' inode are in "bdev" mount, its super_block just > have nr_cached_objects as NULL, > s_nr_dentry_unused and s_nr_inodes_unused both 0, get total_objects to be > reclaimed is 0; > > So is why sysctl_vfs_cache_pressure doesn't give pressure to Buffers, > > > if (sb->s_op && sb->s_op->nr_cached_objects) > fs_objects = sb->s_op->nr_cached_objects(sb); > > total_objects = sb->s_nr_dentry_unused + > sb->s_nr_inodes_unused + fs_objects; > > total_objects = (total_objects / 100) * sysctl_vfs_cache_pressure; > drop_super(sb); > > > In crash, I got to know this block_device (253:2, or /dev/dm-2)has > 10536805 pages mapped, that is the 40GB memory in Buffers, I still do not see why is that a problem. They should get reclaimed on demand. > I wonder is there a sysctl can controll this to be reclaimed earlier? I do not know about any. [...] -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>