On 10-May 17:39, Leo Yan wrote:
Hi Patrick,
Thanks for quick response. Please see below comments.
On Tue, May 10, 2016 at 10:09:18AM +0100, Patrick Bellasi wrote:
[...]
With non-root user in Android, I cannot add PID to SchedTune's cgroup; At beginning I thought it's related with cgroup's file node attribution, so tried to use "root" user to change permission with "a+rwx", even so still cannot set cgroup's node by non-root user.
hikey:/ $ su hikey:/ # chmod a+rwx /sys/fs/cgroup/stune/performance/cgroup.procs hikey:/ # exit
hikey:/ $ echo 1937 > /sys/fs/cgroup/stune/performance/cgroup.procs hikey:/ $ cat /sys/fs/cgroup/stune/performance/cgroup.procs
That's strange, provided that you have node permission (and task 1937 is still alive) what you are doing should work.
I randomly picked up one kernel thread "1937" of kworker, not sure if it's related with this or not? Does this means all kernel threads cannot be set for SchedTune's group or just it's special for "kworker" thread?
Yes and no, some kernel threads are CPU pinned thus for example using a cpuset CGroup you cannot move it, but you get an error on the write syscall.
However, I do NOT expect this limitation to be there when SchedTune CGroups are in use, we do not check any task specific attribute when moving them on boost groups. Unless, there are some "assumptions" in the CGroup core code which does not allow to move kthreads into subgroups...
USER PID PPID VSZ RSS WCHAN PC S NAME root 1937 2 0 0 0 0 S [kworker/2:2]
I've just tryied on a Chromebook and yes, for all kworker I get a: "write error: Invalid argument" for all kworker, both writing on cgroup.procs as well as tasks.
This requires to be better investigated in the CGroup core code because it's inhibiting the boosting of kernel threads :-(
Just one minor note, cgroup.procs reports only TGIDs. If 1937 is a thread of a main process, you should find it listed just under tasks. Thus, usually it's better to check using:
hikey:/ $ cat /sys/fs/cgroup/stune/performance/tasks
Yes, exactly. I tried manually launch tasks, this method can work well:
hikey:/ $ while true; do echo "test" > /dev/zero; sleep 2; done & [1] 2722 hikey:/ $ echo 2722 > /sys/fs/cgroup/stune/performance/tasks
hikey:/ $ while true; do echo "test" > /dev/zero; sleep 2; done & [2] 2726 hikey:/ $ echo 2726 > /sys/fs/cgroup/stune/performance/cgroup.procs
hikey:/ $ cat /sys/fs/cgroup/stune/performance/tasks 2722 2726
Ok, it seems to be working as expected.
However, do you really need to boost kthreads? In that case we have to look at the reasons for them not being moved into a boost group.
Do you have suggestion for what's the formal method for adding PID to SchedTune's cgroup with non-root user?
Here are some guidelines:
- use cgroup.procs to move all the tasks of a thread group
- use tasks to move a single task, specified by PID
- use tasks to check the PIDs of all the tasks in that group
Thanks for summary.
Welcome! ;-)
-- #include <best/regards.h>
Patrick Bellasi