Balbir Singh wrote:
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%
Now your arithmetic is failing you. According to my formula:
1. With one task in group A you give it 10% which is what you get when
you divide 10% by one.
2. With two tasks in group A you give them each somewhere between 5%
(which is 10% divided by 2) and 10%. If they are equally busy you give
them each 5% and if they are not equally busy you give them you give
them larger caps.
Another, probably a better but more expensive, formula is to divide the
10% between them in proportion to their demand. Being careful not to
give any of them a zero cap, of course. I.e. in the two task 10% case
they each get 5% if they are equally busy but if one is twice as busy as
the other it gets a 6.6% cap and the other gets 3.3% (approximately).
Peter
--
Dr Peter Williams, Chief Scientist <[email protected]>
Aurema Pty Limited
Level 2, 130 Elizabeth St, Sydney, NSW 2000, Australia
Tel:+61 2 9698 2322 Fax:+61 2 9699 9174 http://www.aurema.com
-
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]
