linux-kernel - Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction

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, 21 Sep 2006 15:09:47 -0700
From:	"Paul Menage" <menage@...gle.com>
To:	sekharan@...ibm.com
Cc:	npiggin@...e.de, ckrm-tech@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, "Paul Jackson" <pj@....com>,
	rohitseth@...gle.com, devel@...nvz.org, clameter@....com
Subject: Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction

On 9/21/06, Chandra Seetharaman <sekharan@...ibm.com> wrote:
>
> >
> > But, there's no reason that the OpenVZ resource control mechanisms
> > couldn't be hooked into a generic process container mechanism along
> > with cpusets and RG.
>
> Isn't that one of the things we are trying to avoid (each one having
> their own solution, especially when we _can_ have a common solution).

Can we actually have a single common solution that works for everyone,
no matter what their needs? It's already apparent that there are
multiple different and subtly incompatible definitions of what "memory
controller" means and needs to do. Maybe these can be resolved - but
maybe it's better to have, say, two simple but very different memory
controllers that the user can pick between, rather than one big and
complicated one that tries to please everyone.

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/