Messages in this thread | | | Subject | Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps | From | Chandra Seetharaman <> | Date | Fri, 02 Jun 2006 12:06:47 -0700 |
| |
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/
| |