Hi Patrick,
[ + eas-dev ]
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
Do you have suggestion for what's the formal method for adding PID to SchedTune's cgroup with non-root user?
Thanks, Leo Yan
On 10-May 16:35, Leo Yan wrote:
Hi Patrick,
Hi Leo,
[ + eas-dev ]
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.
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
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, Leo Yan
-- #include <best/regards.h>
Patrick Bellasi
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?
USER PID PPID VSZ RSS WCHAN PC S NAME root 1937 2 0 0 0 0 S [kworker/2:2]
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
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.
Thanks, Leo Yan
-- #include <best/regards.h>
Patrick Bellasi
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
On Tue, May 10, 2016 at 11:39:18AM +0100, Patrick Bellasi wrote:
[...]
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 :-(
So actually my question should be for "kworker threads cannot be set for SchedTune CGroups", it's no matther with root's permission at all.
Just want to clarify at here.
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.
No, currently have no obvious user case for boosting kthreads.
Thanks, Leo Yan
Hi Patrick,
On Tue, May 10, 2016 at 11:39: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...
Here have another limitation to set task into SchedTune's CGroup: the user must match with process's UID, then this user can set this task into SchedTune's CGroup. For example, "com.android.smspush" its UID is "u0_a42", so I can add this process into SchedTune's CGroup by two methods:
- Change to root with "su", then can add task into CGroup; - Manually use command "su u0_a42" to firstly switch to user u0_a42, then finally can this user into "tasks" node;
If I login to other users, then cannot add this process into CGroup.
I think this is okay for debugging and experimental testing, but for formal booting sequence in product, I'm curious how we can ensure the executing user is same one with process's UID? Sorry I have very less knowledge for Android's booting sequence, it's interesting these processes are launched by many different users.
USER PID PPID VSZ RSS WCHAN PC S NAME u0_a32 2360 1659 147696 90176 0 0 S com.android.inputmethod.latin radio 2385 1659 148222 92740 0 0 S com.android.phone u0_a7 2390 1659 151780 10242 0 0 S com.android.launcher u0_a26 2484 1659 147063 78208 0 0 S com.android.deskclock u0_a42 2507 1659 146150 53868 0 0 S com.android.smspush u0_a1 2557 1659 146450 73132 0 0 S com.android.providers.calendar u0_a8 2573 1659 146254 57684 0 0 S com.android.managedprovisioning u0_a10 2590 1659 146128 54732 0 0 S com.android.onetimeinitializer
Thanks, Leo Yan
-
Leo Yan -
Patrick Bellasi