Hi Oleg, All I saw an issue of CPU slogging posted in https://lkml.org/lkml/2013/8/28/283, and require your valuable suggestion on a very similar issue I am facing. We are facing the issue of cpu slogging in the function cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk, bool threadgroup) in the do-while loop which iterates over the threadgroup. rcu_read_lock(); do { struct task_and_cgroup ent; /* @tsk either already exited or can't exit until the end */ if (tsk->flags & PF_EXITING) continue; /* as per above, nr_threads may decrease, but not increase. */ BUG_ON(i >= group_size); ent.task = tsk; ent.cgrp = task_cgroup_from_root(tsk, root); /* nothing to do if this task is already in the cgroup */ if (ent.cgrp == cgrp) continue; /* * saying GFP_ATOMIC has no effect here because we did prealloc * earlier, but it's good form to communicate our expectations. */ retval = flex_array_put(group, i, &ent, GFP_ATOMIC); BUG_ON(retval != 0); i++; if (!threadgroup) break; } while_each_thread(leader, tsk); Problem Observed: In this loop, in case of a single thread, and argument “bool threadgroup” as “false” and if(ent.cgrp == cgrp) is true we will continue to the next thread instead of breaking out of the loop. Possible Solution and Doubt: When a break condition was added as shown in the patch attached, the cpu sluggishness was not occurring. Can you please provide your suggestions, if this is the right way to fix the above mentioned issue. Also, if a fix is already in for this, can you please guide me to that. Thanks and Regards Anjana
Attachment:
cgroup_singe_thread_attach.patch
Description: Binary data
