linux-kernel - Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

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:	Thu, 15 Nov 2012 13:25:04 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
cc:	"Kirill A. Shutemov" <kirill@...temov.name>,
	Pekka Enberg <penberg@...nel.org>,
	Mel Gorman <mgorman@...e.de>,
	Leonid Moiseichuk <leonid.moiseichuk@...ia.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Minchan Kim <minchan@...nel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	John Stultz <john.stultz@...aro.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
	patches@...aro.org, kernel-team@...roid.com,
	linux-man@...r.kernel.org
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

On Thu, 15 Nov 2012, Anton Vorontsov wrote:

> Hehe, you're saying that we have to have cgroups=y. :) But some folks were
> deliberately asking us to make the cgroups optional.
> 

Enabling just CONFIG_CGROUPS (which is enabled by default) and no other 
current cgroups increases the size of the kernel text by less than 0.3% 
with x86_64 defconfig:

   text	   data	    bss	    dec	    hex	filename
10330039	1038912	1118208	12487159	 be89f7	vmlinux.disabled
10360993	1041624	1122304	12524921	 bf1d79	vmlinux.enabled

I understand that users with minimally-enabled configs for an optimized 
memory footprint will have a higher percentage because their kernel is 
already smaller (~1.8% increase for allnoconfig), but I think the cost of 
enabling the cgroups code to be able to mount a vmpressure cgroup (which 
I'd rename to be "mempressure" to be consistent with "memcg" but it's only 
an opinion) is relatively small and allows for a much more maintainable 
and extendable feature to be included: it already provides the 
cgroup.event_control interface that supports eventfd that makes 
implementation much easier.  It also makes writing a library on top of the 
cgroup to be much easier because of the standardization.

I'm more concerned about what to do with the memcg memory thresholds and 
whether they can be replaced with this new cgroup.  If so, then we'll have 
to figure out how to map those triggers to use the new cgroup's interface 
in a way that doesn't break current users that open and pass the fd of 
memory.usage_in_bytes to cgroup.event_control for memcg.

> OK, here is what I can try to do:
> 
> - Implement memory pressure cgroup as you described, by doing so we'd make
>   the thing play well with cpusets and memcg;
> 
> - This will be eventfd()-based;
> 

Should be based on cgroup.event_control, see how memcg interfaces its 
memory thresholds with this in Documentation/cgroups/memory.txt.

> - Once done, we will have a solution for pretty much every major use-case
>   (i.e. servers, desktops and Android, they all have cgroups enabled);
> 

Excellent!  I'd be interested in hearing anybody else's opinions, 
especially those from the memcg world, so we make sure that everybody is 
happy with the API that you've described.
--
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/