On 06/25/2015 12:37 AM, John Stultz wrote:
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.
It's a reasonable solutions.
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.
In 3.18 android the timerslack is 43. But the key in user APP, how to make sure the user level APP know the 41 is for THP_DIS and 43 is for TIMERSLACK?
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.
yes, that is best solution.
Anyway, I will look at if we can backport THP_DIS to 3.10 and change the timeslack to 43.
Peter, With all the possible solution, which one is your prefer?
thanks -john