lkml.org 
[lkml]   [2006]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps
Mike Galbraith wrote:
> On Fri, 2006-06-02 at 23:18 +1000, Peter Williams wrote:
>> Mike Galbraith wrote:
>>> On Fri, 2006-06-02 at 15:55 +1000, Peter Williams wrote:
>>>> Chandra Seetharaman wrote:
>>>>> On Thu, 2006-06-01 at 14:04 +0530, Balbir Singh wrote:
>>>>>> Hi, Kirill,
>>>>>>
>>>>>> Kirill Korotaev wrote:
>>>>>>>> Do you have any documented requirements for container resource
>>>>>>>> management?
>>>>>>>> Is there a minimum list of features and nice to have features for
>>>>>>>> containers
>>>>>>>> as far as resource management is concerned?
>>>>>>> Sure! You can check OpenVZ project (http://openvz.org) for example of
>>>>>>> required resource management. BTW, I must agree with other people here
>>>>>>> who noticed that per-process resource management is really useless and
>>>>>>> hard to use :(
>>>>> I totally agree.
>>>> "nice" seems to be doing quite nicely :-)
>>>>
>>>> To me this capping functionality is a similar functionality to that
>>>> provided by "nice" and all that's needed to make it useful is a command
>>>> (similar to "nice") that runs tasks with caps applied.
>>> Similar in that they are both inherited. Very dissimilar in that the
>>> effect of nice is not altered by fork whereas the effect of a cap is.
>>>
>>> Consider make. A cap on make itself isn't meaningful, and _any_ per
>>> task cap you put on it with the intent of managing the aggregate, is
>>> defeated by the argument -j. Per task caps require omniscience to be
>>> effective in managing processes. That's a pretty severe limitation.
>> These caps aren't trying to control aggregates but with suitable
>> software they can be used to control aggregates.
>
> How? How would you deal with the make example with per task caps.

I'd build a resource management tool that uses task statistics, nice and
caps to manage CPU resource allocation. This could be a plug in kernel
module or a user space daemon. It doesn't need to be in the scheduler.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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-03 02:11    [W:1.744 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site