Hi all, I entered a problem when using cgroups on a powerpc board, but I think it's a general problem or question. Whats the status of tasks which are running with SCHED_IDLE and cgroups? The kernel configuration for CGROUPS distinguishes between SCHED_OTHER and SCHED_RT/FIFO. SCHED_IDLE isn't mentioned at all. If I create two threads which are creating load on the cpu with SCHED_IDLE I see that they are sharing the CPU load. If I move one of this tasks to a cgroup I saw that afterwards this task eats up (more or less) all of the CPU load and the other one is starving, even if both are still SCHED_IDLE. It's easy to reproduce with this script (at least on my single 32 bit ppc cpu), which set up a cgroup sets the current shell to SCHED_IDLE, create a task move this one to the cgroup and start the second one: mount -t tmpfs cgroup_root /sys/fs/cgroup mkdir /sys/fs/cgroup/cpu mount -t cgroup -ocpu none /sys/fs/cgroup/cpu cd /sys/fs/cgroup/cpu mkdir browser echo $$ | xargs chrt -i -p 0 dd if=/dev/zero of=/dev/null & pgrep ^dd$ > browser/tasks dd if=/dev/zero of=/dev/null & If you start top you will see that the first dd process eats up the CPU time. If you skip moving the task you would see that both tasks consumes the same load. So my question is. Is this a bug or is it forbidden to move a task into a specific cgroup? If the second statement is true then it may be good to deny such a request e.g.: diff --git a/kernel/cgroup.c b/kernel/cgroup.c index a7c9e6d..b475315 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -2149,6 +2149,11 @@ retry_find_task: rcu_read_unlock(); goto out_unlock_cgroup; } + if (tsk->policy == SCHED_IDLE) { + ret = -EPERM; + rcu_read_unlock(); + goto out_unlock_cgroup; + } get_task_struct(tsk); rcu_read_unlock(); Any opinion on this? Best regards Holger -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html