Peter Williams wrote:
> Balbir Singh wrote:
>
>>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?
>
>
> Well the general idea is correct but your maths is wrong. You'd have to
> give each of them a cap somewhere between 10% and 10% divided by the
> number of tasks in group A. Exactly where in that range would vary
> depending on the CPU demand of each task and would need to be adjusted
> dynamically (unless they were very boring tasks whose demands were
> constant over time).
>
Hmm.. I thought my math was reasonable (but there is always so much to learn)
>From your formula, if I have 1 task in group A, I need to provide it with
a cap of b/w 10 to 11%. For two tasks, I need to give them b/w 10 to 10.5%.
If I have a hundred, it needs to be b/w 10% and 10.01%
>
>>Is there a way to distribute the group limit
>>across tasks in the resource group?
>
>
> Not as part of this patch but it could be done from outside the
> scheduler either in the kernel or in user space.
>
>
>>>>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.
>
>
> No. Read LKML and you'll know as much as I do.
>
>
>>What do the new statistics contain - any heads up on them?
>
>
> There're several contenders (including some from IBM) that periodically
> post patches to LKML. That's where I'm aware of them from. As I say,
> I'm hoping that they get together and come up with something generally
> useful (as opposed to just meeting each contenders needs). I may be
> being overly optimistic but you never know.
Yes, thats the whole point of the discussion and everybody is free to
participate.
>
> Peter
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
