Message-Id: <1154718635.11679.11.camel@linuxchandra>
Date:	Fri, 04 Aug 2006 12:10:35 -0700
From:	Chandra Seetharaman <sekharan@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	dipankar@...ibm.com, 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, 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, 2006-08-03 at 23:45 -0700, Andrew Morton wrote:
> On Fri, 4 Aug 2006 11:50:36 +0530
> Dipankar Sarma <dipankar@...ibm.com> wrote:
> 
> > > And now we've dumped the good infrastructure and instead we've contentrated
> > > on the controller, wired up via some imaginative ab^H^Hreuse of the cpuset
> > > layer.
> > 
> > FWIW, this controller was originally written for f-series.
> 
> What the heck is an f-series?

That is how the latest posting was referred in ckrm-tech mailing list. 
> 
> <googles, looks at
> http://images.automotive.com/cob/factory_automotive/images/Features/auto_shows/2005_IEAS/2005_Ford_F-series_Harley-Davidson_front.JPG,
> gets worried about IBM design methodologies>

he he...
> 
> > 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...
> 
> > > I wonder how many of the consensus-makers were familiar with the
> > > contemporary CKRM core?
> > 
> > I think what would be nice is a clear strategy on whether we need
> > to work out the infrastructure or the controllers first.
> 
> We should put our thinking hats on and decide what sort of infrastructure
> will need to be in place by the time we have a useful number of useful
> controllers implemented.
> 
> > 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?

To some extent yes... 
> 
> > 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

No, not at all. But there were some disagreements w.r.t which interface
to use. So, as pointed by Vatsa in a different email, we wanted to
proceed with controller implementation (where we can get more
agreements) and avoid the controversial topic for now.
> 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!
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@...ibm.com   |      .......you may get it.
----------------------------------------------------------------------


-
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