On Wed, Nov 13, 2013 at 5:02 AM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 11/12/2013 12:38 PM, Zhi Yong Wu wrote: >> On Wed, Nov 13, 2013 at 1:05 AM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >>> The on/off knob seems to me to be something better left to a mount >>> option, not a global tunable. >> If it is left to a mount option, the user or admin can't change it >> *dynamically*. > > Really? > > man mount. Look at "Mount options for tmpfs". Try this on an existing > tmpfs mount: > > mount -o remount,size=$foo tmpfsmount > > How would that be different from your tunable? Is it light weight? I thought that remount will have more overhead and effect on the applications running on filesystem. > >>> If this were true, why don't we have similar knobs for the dentry, inode >>> and page caches? >> This is not be controlled by memory controller(mem_cgroup)? > > That's a good point. There is a 'kmem' cgroup controller for > controlling the in-kernel structures (not page cache which is controlled > by a separate one). I believe the 'kmem' one would (could?) apply to > the hot tracking data structures as well, which would obviate the need > for this tunable. > > At least for the dentry and inode caches, they represent kernel-internal > cache structures and are the same as your hot-data-tracking structures. > We don't have explicit /proc controls for the size of the dentry and > inode caches, so I'm arguing that we should do the same for these new > hot-data-tracking structures. If 'kmem' cgroup controller is applied to VFS hot tracking, need we do some additional coding work in kernel? If yes, we should put it to TODO list. You know, we should push VFS hot tracking core to get merged ASAP at first. Like this interface, we can develop and improve it later. I don't know what Viro's opinion is, If he also agree, we can really put it to TODO list. > -- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html