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: <CAEH94Lis9wwgrcnJrJO3LtLoEc07Ze9T_LwpsjVy_yE4XEydyQ@mail.gmail.com>
Date:	Wed, 13 Nov 2013 04:38:53 +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 1:05 AM, Dave Hansen <dave.hansen@...el.com> wrote:
> On 11/11/2013 02:45 PM, Zhi Yong Wu wrote:
>> On Tue, Nov 12, 2013 at 6:15 AM, Dave Hansen <dave.hansen@...el.com> wrote:
>>> In general, why do you have to control the number of these statically?
>> It gives the user or admin one optional chance to control the amount
>> of memory consumed by VFS hot tracking. And you can choose not to use
>> it.
>
> 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*.

>
>>> Shouldn't you just define a shrinker and let memory pressure determine
>>> how many of these we allow to exist?
>> How about if the user and admin hope to control the amount of the
>> memory consumed by VFS hot tracking? e.g. If the host has several
>> hundred of G or T memory, but the user or admin hope that the memory
>> size consumed by VFS hot tracking is under several G, In the case,
>> maybe a shrinker of VFS hot tracking will never be invoked by system
>> memory module, so this interface will make sense.
>
> If the shrinker is not invoked, that means that there is lots of memory
> free.  In the case that there is lots of memory free, are you arguing
> that a user would rather see memory go *unused* than be put to use for
> this hot tracking data?
At first, some user or admin has a lot of use cases which you can't imagine.
If he hope that the usage of memory consumed by VFS hot tracking
doesn't affect other key applications, how about it? This only give
one fine-grained control to the usage of memory consumed by VFS hot
tracking.
>
> 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)?



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