linux-kernel - Re: [ckrm-tech] [PATCH] BC: resource beancounters (v4) (added user memory)

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: <1158084138.20211.26.camel@galaxy.corp.google.com>
Date:	Tue, 12 Sep 2006 11:02:18 -0700
From:	Rohit Seth <rohitseth@...gle.com>
To:	vatsa@...ibm.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 Tue, 2006-09-12 at 23:10 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 12, 2006 at 10:22:32AM -0700, Rohit Seth wrote:
> > On Tue, 2006-09-12 at 16:14 +0530, Srivatsa Vaddagiri wrote:
> > > 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 a user is really interested in ensuring that all scheduled jobs (or
> > containers) get what they have asked for (guarantees) then making the
> > sum of all container limits equal to total system limit is the right
> > thing to do.
> > 
> > > If it is setup like that, then what you are considering as limit is
> > > actually guar no?
> > > 
> > Right.  And if we do it like this then it is up to sysadmin to configure
> > the thing right without adding additional logic in kernel.
> 
> Perhaps calling it as "limit" in confusing then (otoh it may go down well
> with Linus!).

It is similar to what ulimit generally implies.  It will definitely help
getting container code in mainline if we can minimize the changes in
mainline but still providing some meaningful functionality.

CKRM is excellent piece of code but I think its complexity is what
making it sit out side the mainline for such a long period of time.

>  I perhaps agree we need to go with one for now (in the
> interest of making some progress), but we probably will come back to
> this at a later point. 

Indeed if there are still some requirements.

-rohit

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