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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux