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]

Message-ID: <20121115085224.GA4635@lizard>
Date:	Thu, 15 Nov 2012 00:52:24 -0800
From:	Anton Vorontsov <anton.vorontsov@...aro.org>
To:	David Rientjes <rientjes@...gle.com>
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, Nov 15, 2012 at 12:11:47AM -0800, David Rientjes wrote:
[...]
> Might not be too difficult if you implement your own cgroup to aggregate 
> these tasks for which you want to know memory pressure events; it would 
> have to be triggered for the task trying to allocate memory at any given 
> time and how hard it was to allocate that memory in the slowpath, tie it 
> back to that tasks' memory pressure cgroup, and then report the trigger if 
> it's over a user-defined threshold normalized to the 0-100 scale.  Then 
> you could co-mount this cgroup with memcg, cpusets, or just do it for the 
> root cgroup for users who want to monitor the entire system

This seems doable. But

> (CONFIG_CGROUPS is enabled by default).

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

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;

- 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);

(- Optionally, if there will be a demand, for CGROUPS=n we can implement a
separate sysfs file with the exactly same eventfd interface, it will only
report global pressure. This will be for folks that don't want the cgroups
for some reason. The interface can be discussed separately.)

Thanks,
Anton.
--
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/