linux-kernel - Re: [mm] [PATCH 4/4] Memory cgroup hierarchy feature selector

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: <6599ad830811032237q14c065efx4316fee8f8daa515@mail.gmail.com>
Date:	Mon, 3 Nov 2008 22:37:31 -0800
From:	Paul Menage <menage@...gle.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm@...ck.org, YAMAMOTO Takashi <yamamoto@...inux.co.jp>,
	lizf@...fujitsu.com, linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Rientjes <rientjes@...gle.com>,
	Pavel Emelianov <xemul@...nvz.org>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [mm] [PATCH 4/4] Memory cgroup hierarchy feature selector

On Sun, Nov 2, 2008 at 7:52 AM, Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
>
> That should not be hard, but having it per-subtree sounds a little complex in
> terms of exploiting from the end-user perspective and from symmetry perspective
> (the CPU cgroup controller provides hierarchy control for the full hierarchy).
>

The difference is that the CPU controller works in terms of shares,
whereas memory works in terms of absolute memory size. So it pretty
much has to limit the hierarchy to a single tree. Also, I didn't think
that you could modify the shares for the root cgroup - what would that
mean if so?

With this patch set as it is now, the root cgroup's lock becomes a
global memory allocation/deallocation lock, which seems a bit painful.
Having a bunch of top-level cgroups each with their own independent
memory limits, and allowing sub cgroups of them to be constrained by
the parent's memory limit, seems more useful than a single hierarchy
connected at the root.

In what realistic circumstances do you actually want to limit the root
cgroup's memory usage?

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