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]

Message-ID: <52829751.2090105@intel.com>
Date:	Tue, 12 Nov 2013 13:02:09 -0800
From:	Dave Hansen <dave.hansen@...el.com>
To:	Zhi Yong Wu <zwu.kernel@...il.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 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?

>> 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.

--
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/