Re: [ckrm-tech] [PATCH 0/4] sched: Add CPU rate caps

[Peter Williams <peterw@aurema.com>]

Chris Friesen wrote:
> Peter Williams wrote:
>> These patches implement CPU usage rate limits for tasks.
> 
> Personally, I'm more comfortable with guarantees rather than limits.

It's not an "either or" situation.  You can have both.

As I said recently in other mail on this topic, the only thing that 
needs to be resolved when you have both caps and guarantees is which one 
has precedence if they conflict.  Of course, one solution to this is to 
disallow conflicting caps and guarantees but that is really just the 
same as saying whichever was set first has precedence.

> 
> Specifying a limit doesn't do anything to ensure that a task (or group 
> of tasks) gets enough cpu time to actually accomplish anything unless 
> you specify limits on every task in the system.

No, but it can be used to make sure certain tasks don't hog the CPU and 
prevent other tasks from getting their job done.

> 
> Suppose you have a server app that needs at least 50% of the cpu.  With 
> a guarantee, you can say "this guy needs 50%, and I don't care about 
> anything else".  With limits you have to flip it around--"all these guys 
> together are limited to 50%, and that guy isn't limited".  Seems 
> counterintuitive.

Yes, guarantees would be better for that problem but this doesn't mean 
that caps are useless.  Also an equivalent situation where caps are a 
better solution to guarantees would be easy to generate.  Ergo both 
mechanisms are useful.

For the ordinary user, I think that the most useful feature of this 
patch is the ability to impose a soft cap of zero on a task and for that 
cap to be inherited by its children (which it is).  This is a very 
useful for running a job (such as a kernel build) in the background.  If 
you look at the kernbench numbers that I enclosed you will note that, in 
the absence of other load on the computer, the increase in the build 
time using this feature is very small.  The advantages of having the 
build run in the background are improved responsiveness for those 
interactive tasks we're using (e.g. editing files, reading/writing mail 
etc.) while the build is in progress.

Peter
-- 
Dr Peter Williams, Chief Scientist         <peterw@aurema.com>
Aurema Pty Limited
Level 2, 130 Elizabeth St, Sydney, NSW 2000, Australia
Tel:+61 2 9698 2322  Fax:+61 2 9699 9174 http://www.aurema.com