Date:	Tue, 13 Oct 2009 18:26:14 +0530
From:	Dhaval Giani <dhaval@...ux.vnet.ibm.com>
To:	Pavel Emelyanov <xemul@...nvz.org>
Cc:	Herbert Poetzl <herbert@...hfloor.at>, vatsa@...ibm.com,
	Bharata B Rao <bharata@...ux.vnet.ibm.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Gautham R Shenoy <ego@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Avi Kivity <avi@...hat.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Paul Menage <menage@...gle.com>,
	Mike Waychison <mikew@...gle.com>
Subject: Re: [RFC v2 PATCH 0/8] CFS Hard limits - v2

On Tue, Oct 13, 2009 at 04:45:15PM +0400, Pavel Emelyanov wrote:
> Dhaval Giani wrote:
> > On Tue, Oct 13, 2009 at 04:19:41PM +0400, Pavel Emelyanov wrote:
> >>> as I already stated, it seems perfectly fine for me 
> >> You're not the only one interested in it, sorry. Besides, I
> >> got your point in "I'm find with it". Now get mine which is
> >> about "I am not".
> >>
> >>> can be trivially mapped to the two values, by chosing a
> >>> fixed multiplicative base (let's say '1s' to simplify :) 
> >>>
> >>>   with 50%, you get 1s/0.5s
> >>>   with 20%, you get 1s/0.2s
> >>>   with  5%, you get 1s/0.05s
> >>>
> >>> well, you get the idea :)
> >> No I don't.
> >> Is 1s/0.5s worse or better than 2s/1s?
> >> How should I make a choice?
> > 
> > I would say it depends on your requirement. How fast do you want to
> > respond back to the user? Wiht lower bandwidth, you would want to have
> > shorter periods so that the user would not get the impression that he
> > has to "wait" to get CPU time. But having a very short period is not a
> > good thing, since there are other considerations (such as the overhead of
> > hard limits).
> 
> That's it - long period is bad for one reason, short period is bad for 
> some other one and neither of them is clearly described unlike the 
> limit itself.
> 
> In other words there are two numbers we're essentially playing with:
> * the limit (int percents, Hz, whatever)
> * and this abstract "badness"
> 
> Can't we give the user one of them for "must be configured" usage, put
> the other one in some "good for most users" position and let the user
> move it later on demand?
> 

Right, but is this not more of a policy decision as opposed to an
infrastructure one and better handled in userspace?

> Yet again - weights in CFQ CPU-sched, ionoce in CFQ-iosched, bandwidth
> in tc (traffic shaping), etc. are all clean for end-user. Plus there are
> other fine tunes, that user should not configure by default, but which
> change the default behavior. I propose to create simple and clean 
> interface for limits as well. If you think that virtual cpu power is 
> not good, ok. Let's ask user for a percentage and give him yet another
> option to control this "badness" or "responsiveness".
> 

How is virtual cpu power defined? GHz is not a clear definition. It
means different things (in terms of performance) for different
processors. Do you want to define it as getting x cycles of a CPU in
y seconds for the cgroup, or do you want to define it as a certain number
of operations in a second. If it is the former, I think we can map it to
the current interface in userspace itself.  Why don't we define this
metric, and then look to solve the problem? 

thanks,
-- 
regards,
Dhaval
--
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