Messages in this thread | | | Date | Fri, 26 Jun 2015 14:36:07 -0700 | Subject | Re: [RFC][PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread. | From | John Stultz <> |
| |
On Thu, Jun 25, 2015 at 6:21 PM, Arjan van de Ven <arjan@linux.intel.com> wrote: > On 6/25/2015 4:24 PM, John Stultz wrote: >> >> From: Ruchi Kandoi <kandoiruchi@google.com> >> >> This patch has been in the Android tree for ahwile, and I've not >> seen it posted for review. Unfortunately the PR_SET_TIMERSLACK_PID >> value has collided many times w/ upstream (first w/ >> PR_SET_THP_DISABLE, and again w/ PR_MPX_ENABLE_MANAGEMENT). >> >> So to try to avoid further ABI trouble, I wanted to send this out >> for initial review to see if there were any major objections, >> or ideas for alternative approaches. >> >> Thoughts and feedback would be appreciated. > > > I am wondering if it would be more natural to make this a cgroup > property.. and have a way for threads to inherit their cgroup > effective value.
I'm hesitant here, as I know the android cgroup usage (ie: having a forground cgroup and background cgroup), is frowned upon by the cgroup maintainers, since frequently migrating processes and memory between the cgroups is costly. So they've been suggesting (assuming I understood their feedback properly) to use per-application cgroups (changing the cgroup knobs to "forground settings" or "background settings") as needed.
So if you were thinking that one could set the slack for larger cgroups to avoid per-process adjustments, that may not be the right way forward. But maybe you're suggesting something else?
> it'll fit more natural in many places than just a per pid setting. > (I have nothing against it per se other than that I think the > security check is wrong; I fully expected to be on the level of > ptrace_may_access(PTRACE_MODE_ATTACH) or the like.. not just NICE. > you can seriously change task behavior with this by setting a 4 second > value or so.. much more than just with nice)
Yea, they've sort of overloaded CAP_SYS_NICE for a number of Android specific checks. I think using a different existing cap or introducing a new one would be fine, but I'm not sure which cap would really be best. Are there any other opinions here, or is PTRACE_MODE_ATTACH ok?
thanks -john
| |