Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps

[Chandra Seetharaman <sekharan@us.ibm.com>]

On Fri, 2006-06-02 at 13:21 +1000, Peter Williams wrote:
> Chandra Seetharaman wrote:
> > On Fri, 2006-06-02 at 09:26 +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.
> >>>> I'll take a look at the references. I agree with you that it will be useful
> >>>> to have resource management for a group of tasks.
> >> But you don't need something as complex as CKRM either.  This capping
> > 
> > All CKRM^W Resource Groups does is to group unrelated/related tasks to a
> > group and apply resource limits. 
> > 
> >>  
> >> functionality coupled with (the lamented) PAGG patches (should have been 
> >> called TAGG for "task aggregation" instead of PAGG for "process 
> >> aggregation") would allow you to implement a kernel module that could 
> >> apply caps to arbitrary groups of tasks.
> > 
> > I do not follow how PAGG + this cap feature can be used to put cap of
> > related/unrelated tasks. Can you provide little more explanation,
> > please.
> 
> I would have thought it was fairly obvious.  PAGG supplies the task 
> aggregation mechanism, these patches provide per task caps and all 
> that's needed is the code that marries the two.

May be obvious from your usage point of view. It wasn't for what i was
thinking as resource management.

I thought there is some way the user can associate some amount of
resources (limits and guarantees) to a PAGG group and move the
corresponding tasks to that PAGG and that is all needed from user
space. 

In other words i thought there is some clever way to manage resources at
the PAGG level (without needing to tinker with the per task caps), which
wasn't obvious for me, and it is now clear that is not the case, and one
still have to keep tweaking the "per task" caps to get the result they
want. 

>From your explanation, complex stuff need to happen in the user space to
manage resource for a group of tasks.

Knobs that are available to the user are
 - per task nice values
 - per task cap limits and
 - per task statistics, if and when they become available.

user level application has to constantly monitor the stats of _all_ the
tasks and constantly keep changing the knobs if they want to keep the
"group of tasks" within their guarantees and limits. As others pointed
already, this may still _not_ yield what one wants, if you have tasks
with disparate need for a resource.

I certainly do not see it as the result of a simple marriage between
PAGG and "per task caps".
> 
> > 
> > Also, i do not think it can provide guarantees to that group of tasks.
> > can it ?
> 
> It could do that by manipulating nice which is already available in the 
> kernel.
> 
> I.e. these patches plus improved statistics (which are coming, I hope) 
> together with the existing policy controls provide all that is necessary 
> to do comprehensive CPU resource control.  If there is an efficient way 
> to get the statistics out to user space (also coming, I hope) this 
> control could be exercised from user space.
> 
> Peter
-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------


-
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/