[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060912104410.GA28444@in.ibm.com>
Date: Tue, 12 Sep 2006 16:14:10 +0530
From: Srivatsa Vaddagiri <vatsa@...ibm.com>
To: Rohit Seth <rohitseth@...gle.com>
Cc: sekharan@...ibm.com, Rik van Riel <riel@...hat.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
CKRM-Tech <ckrm-tech@...ts.sourceforge.net>, balbir@...ibm.com,
Dave Hansen <haveblue@...ibm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...e.de>, Christoph Hellwig <hch@...radead.org>,
Andrey Savochkin <saw@...ru>,
Matt Helsley <matthltc@...ibm.com>,
Hugh Dickins <hugh@...itas.com>,
Alexey Dobriyan <adobriyan@...l.ru>,
Kirill Korotaev <dev@...ru>, Oleg Nesterov <oleg@...sign.ru>,
devel@...nvz.org, Pavel Emelianov <xemul@...nvz.org>
Subject: Re: [ckrm-tech] [PATCH] BC: resource beancounters (v4) (added user memory)
On Mon, Sep 11, 2006 at 12:10:31PM -0700, Rohit Seth wrote:
> It seems that a single notion of limit should suffice, and that limit
> should more be treated as something beyond which that resource
> consumption in the container will be throttled/not_allowed.
The big question is : are containers/RG allowed to use *upto* their
limit always? In other words, will you typically setup limits such that
sum of all limits = max resource capacity?
If it is setup like that, then what you are considering as limit is
actually guar no?
If it wont be setup like that, then I dont see how one can provide QoS.
--
Regards,
vatsa
-
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