Re: [RFC v2 PATCH 0/8] CFS Hard limits - v2

[Bharata B Rao]

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?

This is what we have right now. All the groups will start with a default
period (of .5s) and user has the option of changing it based on his
requirement. However we need to find out if the default period is really
"good for most users"

Regards,
Bharata.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/