Hi,
I've been testing how this works in practice, and I have few
configurations I'm not sure why they behave the way they do.
All the test processes just drain cpu with an infinite loop.
All of them are pinned to single cpu core. cgroup with just
-o cpu is mounted, and the scenario is following (in brackets
- assigned cpu.shares):
root(1024)
/ \
Y(1024) X(4096)
/ \
A(8192) B(8192)
Four test processes sit in X, Y, A and B; root is "empty"
(effectively idle processes). The one in Y expectedly gets
20% cpu, A and B divide the cpu share equally, but - why do
the process in X gets only ~4.75% ? Essentially:
11:36:45 PM PID %usr %system %guest %CPU CPU Command
11:36:50 PM 29472 20.00 0.00 0.00 20.00 1 loadme(y)
11:36:50 PM 29473 4.80 0.00 0.00 4.80 1 loadme(x)
11:36:50 PM 29474 37.60 0.00 0.00 37.60 1 loadme(a)
11:36:50 PM 29475 37.60 0.00 0.00 37.60 1 loadme(b)
In the other words - what is the intended relation between ancestor's
cpu.shares and its children ? Looking at the example above, it looks
like the task in X should get 4/5 (root unused, 1/5 for Y, the rest
for X subtree) * 1/5 (from assigned values in X subtree,
4096/20480) - but that would be ~16%.
The task in X behaves like if X had 1024 - maybe it's always assumed
when parent-children relationship is considered, and the actual value
is used only when dividing cpu between siblings ?
If I move the test task from X to root, the situation will change to:
11:56:49 PM PID %usr %system %guest %CPU CPU Command
11:56:54 PM 29472 16.60 0.00 0.00 16.60 1 loadme(y)
11:56:54 PM 29473 16.60 0.00 0.00 16.60 1 loadme(root)
11:56:54 PM 29474 33.20 0.20 0.00 33.40 1 loadme(a)
11:56:54 PM 29475 33.40 0.00 0.00 33.40 1 loadme(b)
In this scenario, everything seems as expected - 1/6 for Y, 1/6 for root,
4/6 for X subtree.
On Wed, Feb 16, 2011 at 8:11 AM, Michal Soltys <[email protected]> wrote:
> Hi,
>
> I've been testing how this works in practice, and I have few
> configurations I'm not sure why they behave the way they do.
>
> All the test processes just drain cpu with an infinite loop.
> All of them are pinned to single cpu core. cgroup with just
> -o cpu is mounted, and the scenario is following (in brackets
> - assigned cpu.shares):
>
> root(1024)
> / \
> Y(1024) X(4096)
> / \ \
> A(8192) B(8192) task-x(1024)
I assume loadme(x) is an process of group X, like above.
If so, there isn't any problem with it.
Thanks,
Yong
>
> Four test processes sit in X, Y, A and B; root is "empty"
> (effectively idle processes). The one in Y expectedly gets
> 20% cpu, A and B divide the cpu share equally, but - why do
> the process in X gets only ~4.75% ? Essentially:
>
> 11:36:45 PM PID %usr %system %guest %CPU CPU Command
> 11:36:50 PM 29472 20.00 0.00 0.00 20.00 1 loadme(y)
> 11:36:50 PM 29473 4.80 0.00 0.00 4.80 1 loadme(x)
> 11:36:50 PM 29474 37.60 0.00 0.00 37.60 1 loadme(a)
> 11:36:50 PM 29475 37.60 0.00 0.00 37.60 1 loadme(b)
>
> In the other words - what is the intended relation between ancestor's
> cpu.shares and its children ? Looking at the example above, it looks
> like the task in X should get 4/5 (root unused, 1/5 for Y, the rest
> for X subtree) * 1/5 (from assigned values in X subtree,
> 4096/20480) - but that would be ~16%.
>
> The task in X behaves like if X had 1024 - maybe it's always assumed
> when parent-children relationship is considered, and the actual value
> is used only when dividing cpu between siblings ?
>
> If I move the test task from X to root, the situation will change to:
>
> 11:56:49 PM PID %usr %system %guest %CPU CPU Command
> 11:56:54 PM 29472 16.60 0.00 0.00 16.60 1 loadme(y)
> 11:56:54 PM 29473 16.60 0.00 0.00 16.60 1 loadme(root)
> 11:56:54 PM 29474 33.20 0.20 0.00 33.40 1 loadme(a)
> 11:56:54 PM 29475 33.40 0.00 0.00 33.40 1 loadme(b)
>
> In this scenario, everything seems as expected - 1/6 for Y, 1/6 for root,
> 4/6 for X subtree.
>
> --
> 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/
>
--
Only stand for myself