lkml.org 
[lkml]   [2006]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ckrm-tech] [PATCH 0/4] sched: Add CPU rate caps
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-20 01:32    [W:0.107 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site