Peter Williams wrote:
<snip>
>>>
>>>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.
>
The problem is that with per-task caps, if I have a resource group A
and I want to limit it to 10%, I need to limit each task in resource
group A to 10% (which makes resource groups not so useful). Is my
understanding correct? Is there a way to distribute the group limit
across tasks in the resource group?
>
>>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.
Could you please provide me with a link to the new improved statistics.
What do the new statistics contain - any heads up on them?
>
> Peter
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
