| 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
| ||
|
Message-ID: <6599ad830609211509x17f0306qbe6d0ef86b86cbc9@mail.google.com> 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/
Powered by blists - more mailing lists