On Wed, Jun 24, 2015 at 12:59 AM, Amit Pundir amit.pundir@linaro.org wrote:
- John and Sumit for comments,
On 24 June 2015 at 06:22, Alex Shi alex.shi@linaro.org wrote:
CC AmitP and linaro kernel,
Apparently, some APPs are very aggressive using v3.15 kernel's header, since PR_SET_THP_DISABLE is introduced from 3.15. and PR_SET_TIMERSLACK_PID never appears in mainline kernel, only in android.
Amit,
Guess we need to revert this SET_TIMERSLACK_PID if APP keep using DHP_DIS. Any concern/suggestion of this issue?
I'm not sure if reverting SET_TIMERSLACK_PID patch in lsk-3.10-android kernel is a good call here. A quick search show that AOSP master still use SET_TIMERSLACK_PID to set/change the scheduling priority[1] of the background binder and art threads, to name a few.
Yea. I suspect for the Android lsk kernel we will want to add a Kconfig option, which will enable either SET_TIMERSLACK_PID or PR_SET_THP_DISABLE, so that only one is supported at a time. That way for non-android kernels the TIMERSLACK can be effectively dropped at build time, and for android kernels we can preserve it.
If we are running into significant performance hit with APPs using PR_SET_THP_DISABLE on Android kernel, with conflicting prctl value of SET_TIMERSLACK_PID, then we should either just submit a change in AOSP to update SET_TIMERSLACK_PID value accordingly
Yea. We should look at what they did for the 3.18 kernel since it seems like it would have hit this problem already.
and/or also try to backport PR_SET_THP_DISABLE to aosp/android-3.10 kernel if we have a significant usecase for that. Let me know if it make any sense.
Is there any context about which app is using this? If we want to be super clever, we might be able to check if two or three arguments were passed to us, and use that info to decide if its likely SET_THP_DISABLE usage or SET_TIMERSLACK_PID.
But long term, we need to get TIMERSLACK_PID renumbered and pushed upstream.
thanks -john