[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6599ad830906050257q60e124dbt20dea7c6065f1edc@mail.gmail.com>
Date: Fri, 5 Jun 2009 02:57:50 -0700
From: Paul Menage <menage@...gle.com>
To: balbir@...ux.vnet.ibm.com
Cc: bharata@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Gautham R Shenoy <ego@...ibm.com>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Pavel Emelyanov <xemul@...nvz.org>,
Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
Linux Containers <containers@...ts.linux-foundation.org>,
Herbert Poetzl <herbert@...hfloor.at>
Subject: Re: [RFC] CPU hard limits
On Fri, Jun 5, 2009 at 2:55 AM, Balbir Singh<balbir@...ux.vnet.ibm.com> wrote:
> The point is that there is no single control entity for creating
> groups. if run a solution, it might create groups without telling the
> user. No one is arbitrating, not even libcgroup. What if someone
> changes the cpuset assignment and moves CPUS x to y in an exclusive
> cpuset all of a sudden. How do we arbitrate?
But in that situation, how do hard limits help? If you can't control
when cgroups are being created, and you can't control their shares,
how are you going to control their hard limits?
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