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:	Tue, 12 Nov 2013 06:45:37 +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 Tue, Nov 12, 2013 at 6:15 AM, Dave Hansen <dave.hansen@...el.com> wrote:
> On 11/06/2013 05:45 AM, Zhi Yong Wu wrote:
>> Introduce a /proc interface hot-mem-high-thresh and
>> to cap the memory which is consumed by hot_inode_item
>> and hot_range_item, and they will be in the unit of
>> 1M bytes.
>
> You don't seem to have any documentation for this, btw... :(
>
>> +             .procname       = "hot-mem-high-thresh",
>
> *Always* put units on these.  I know you mention it in a code comment,
> but please also include it in the proc filename too.
If you think it is better, i will add it.
>
> 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.
> 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.



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ