linux-kernel - Re: [RFC, PATCH 0/5] Going forward with Resource Management

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: <20060804071009.GA15141@in.ibm.com>
Date:	Fri, 4 Aug 2006 12:40:09 +0530
From:	Dipankar Sarma <dipankar@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	vatsa@...ibm.com, mingo@...e.hu, nickpiggin@...oo.com.au,
	sam@...ain.net, linux-kernel@...r.kernel.org, dev@...nvz.org,
	efault@....de, balbir@...ibm.com, sekharan@...ibm.com,
	nagar@...son.ibm.com, haveblue@...ibm.com, pj@....com
Subject: Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller

On Thu, Aug 03, 2006 at 11:45:37PM -0700, Andrew Morton wrote:
> On Fri, 4 Aug 2006 11:50:36 +0530
> > 
> > FWIW, this controller was originally written for f-series.
> 
> What the heck is an f-series?

Sorry, the resource group - (formerly ckrm) series that Chandra posted 
a few months ago. 

http://lkml.org/lkml/2006/4/27/378

> > It should
> > be trivial to put it back there. So really, f-series isn't gone 
> > anywhere. If you want to merge it, I am sure it can be re-submitted.
> 
> Well.  It shouldn't be a matter of what I want to merge - you're the
> resource-controller guys.  But...

The point is that putting the controller back to the ckrm framework
would not be that difficult since it came from there.

> > One of
> > the strongest points raised in the BoF was - forget the infrastructure
> > for now, get some mergable controllers developed.
> 
> I wonder what inspired that approach.  Perhaps it was a reaction to CKRM's
> long and difficult history?  Perhaps it was felt that doing standalne
> controllers with ad-hoc interfaces would make things easier to merge?
> 
> Perhaps.  But I think you guys know that the end result would be inferior,
> and that getting good infrastructure in place first will produce a better
> end result, but you decided to go this way because you want to get
> _something_ going?

I think part of it was the fact that the two main controllers
would were in scheduler and VM code made people to be
more cautious about the controllers and wanted those issues
to be sorted out first.

> > If you
> > want to stick to f-series infrastructure and want to see some
> > consensus controllers evolve on top of it, that can be done too.
> 
> Do you think that the CKRM core as last posted had any unnecessary
> features?  I don't have the operational experience to be able to judge
> that, so I'd prefer to trust your experience and judgement on that.  But
> the features which _were_ there looked quite OK from an implementation POV.
> 
> So my take was "looks good, done deal - let's go get some sane controllers
> working".  And now this!

My recollection from the BoF is that people felt interface wasn't a major
issue and it wasn't discussed much. Most of the discussion centered
around grouping of tasks and the mem/cpu controllers and some additional
resource control requirements from openvz folks.

One way to go forward with the interface could be to request Chandra
to repost the ckrm infrastructure and see if the stake holders (primarily
container folks) can review and agree on it.

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