On Thu, Jun 25, 2015 at 3:28 PM, John Stultz john.stultz@linaro.org wrote:
On Thu, Jun 25, 2015 at 7:37 AM, Alex Shi alex.shi@linaro.org wrote:
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.
Just as a heads up, in mainline we have:
#define PR_MPX_ENABLE_MANAGEMENT 43 #define PR_MPX_DISABLE_MANAGEMENT 44 #define PR_SET_FP_MODE 45 #define PR_GET_FP_MODE 46
So it might be good to suggest SET_TIMERSLACK_PID to be set to a large number so we avoid constant collsions while it is out of tree.
Spurred by this, I've folded the related patches together and submitted for comment to lkml. https://lkml.org/lkml/2015/6/25/691
thanks -john