linux-kernel - Re: [PATCH v6 07/11] VFS hot tracking: Add a /proc interface to control memory usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Nov 2013 05:56:24 +0800
From:	Zhi Yong Wu <zwu.kernel@...il.com>
To:	Dave Hansen <dave.hansen@...el.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	linux-kernel mlist <linux-kernel@...r.kernel.org>,
	Zhi Yong Wu <wuzhy@...ux.vnet.ibm.com>,
	Chandra Seetharaman <sekharan@...ibm.com>
Subject: Re: [PATCH v6 07/11] VFS hot tracking: Add a /proc interface to
 control memory usage

On Wed, Nov 13, 2013 at 5:02 AM, Dave Hansen <dave.hansen@...el.com> 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@...el.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/