Hi Alex,
Robin asked me to share with you the patches that I found having conflicts on the Juno LSK integration branch. It would be helpful to know your feelings about them (are they fundamental? can they be dropped? etc.). The aim here is to understand if we can eventually come up with a sched-upstream branch that is more easily applicable on top of the Juno integration branch:
http://git.linaro.org/landing-teams/working/arm/kernel.git integration-lsk-3.10-juno-android
I'll try to give you a list of patches that I had to remove or revert from sched-upstream when trying to build a branch that supports Juno and has EASv3 on top (so that we could test it on Android). I'll also add comments about patches that I'm more familiar with. Please be aware that I had to come up with this in quite a hurry, as we wanted to show EAS results coming from Juno at the last Connect. This means that the rationale for deciding to keep or drop a patch in the branch was merely "drop everything that seems to have non trivial conflicts". At the end I was fairly happy with the behaviours, but this doesn't necessarily mean that we still not need some of what I dropped.
080bdd1 exit.c: unexport __set_special_pids() cdba026 ptrace: revert "Prepare to fix racy accesses on task breakpoints" 73bcb2e mm: remove free_area_cache 802d8c2 ptrace/x86: revert "hw_breakpoints: Fix racy access to ptrace breakpoints" 6472001 ptrace/arm: revert "hw_breakpoints: Fix racy access to ptrace breakpoints"
f0a709a sched: Add new scheduler syscalls to support an extended scheduling parameters ABI 631db36 sched/core: Fix htmldocs warnings 4f89001 sched: Preserve the nice level over sched_setscheduler() and sched_setparam() calls c9d415b sched: Fix up scheduler syscall LTP fails 0525ffc sched: Fix up attr::sched_priority warning b62aed3 sched: Move SCHED_RESET_ON_FORK into attr::sched_flags 7d214b1 sched: Fix __sched_setscheduler() nice test 9db9c75 sched: Fix information leak in sys_sched_getattr() 10d4f89 sched: Add 'flags' argument to sched_{set,get}attr() syscalls
as this preceding set comes with the (or are subsequent fixes of) the SCHED_DEADLINE patchset, I think we could just ignore them for now
02fee98 ARM: introduce common set_auxcr/get_auxcr functions
6a4f9e7 sched: Implement task_nice() as static inline function
this preceding patch is maybe not a crucial fix?
6261e04 sched: Adjust p->sched_reset_on_fork when nothing else changes 33e8006 sched: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE
this two preceding patches depend on 6a4f9e7
15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu()
And finally apply the attached patches to make the branch compile.
Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :).
Best,
- Juri
On 04/24/2015 09:25 PM, Juri Lelli wrote:
Hi Alex,
Robin asked me to share with you the patches that I found having conflicts on the Juno LSK integration branch. It would be helpful to know your feelings about them (are they fundamental? can they be dropped? etc.). The aim here is to understand if we can eventually come up with a sched-upstream branch that is more easily applicable on top of the Juno integration branch:
http://git.linaro.org/landing-teams/working/arm/kernel.git integration-lsk-3.10-juno-android
I'll try to give you a list of patches that I had to remove or revert from sched-upstream when trying to build a branch that supports Juno and has EASv3 on top (so that we could test it on Android). I'll also add comments about patches that I'm more familiar with. Please be aware that I had to come up with this in quite a hurry, as we wanted to show EAS results coming from Juno at the last Connect. This means that the rationale for deciding to keep or drop a patch in the branch was merely "drop everything that seems to have non trivial conflicts". At the end I was fairly happy with the behaviours, but this doesn't necessarily mean that we still not need some of what I dropped.
080bdd1 exit.c: unexport __set_special_pids() cdba026 ptrace: revert "Prepare to fix racy accesses on task breakpoints" 73bcb2e mm: remove free_area_cache 802d8c2 ptrace/x86: revert "hw_breakpoints: Fix racy access to ptrace breakpoints" 6472001 ptrace/arm: revert "hw_breakpoints: Fix racy access to ptrace breakpoints"
f0a709a sched: Add new scheduler syscalls to support an extended scheduling parameters ABI 631db36 sched/core: Fix htmldocs warnings 4f89001 sched: Preserve the nice level over sched_setscheduler() and sched_setparam() calls c9d415b sched: Fix up scheduler syscall LTP fails 0525ffc sched: Fix up attr::sched_priority warning b62aed3 sched: Move SCHED_RESET_ON_FORK into attr::sched_flags 7d214b1 sched: Fix __sched_setscheduler() nice test 9db9c75 sched: Fix information leak in sys_sched_getattr() 10d4f89 sched: Add 'flags' argument to sched_{set,get}attr() syscalls
as this preceding set comes with the (or are subsequent fixes of) the SCHED_DEADLINE patchset, I think we could just ignore them for now
That's ok to remove them.
02fee98 ARM: introduce common set_auxcr/get_auxcr functions
6a4f9e7 sched: Implement task_nice() as static inline function
this preceding patch is maybe not a crucial fix?
6261e04 sched: Adjust p->sched_reset_on_fork when nothing else changes
This one seems a function fix. Could we keep this one?
33e8006 sched: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE
this two preceding patches depend on 6a4f9e7
It's ok to remove above commits.
15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints
Did preceding commits' function support in juno tree, or they were replaced by other commits? Is juno cpuidle driver happy without them?
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu()
Above commits are related with performance&power when system has more clusters. remove them may cuase perf/power issue in some cases.
And finally apply the attached patches to make the branch compile.
They're ok.
Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :).
Hi Juri,
What's cause conflict with about commits, HMP or some android sched change? Looks few of commit can be clean up, like deadline related.
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
Hi Alex,
On 28/04/15 10:38, Alex Shi wrote:
On 04/24/2015 09:25 PM, Juri Lelli wrote:
Hi Alex,
Robin asked me to share with you the patches that I found having conflicts on the Juno LSK integration branch. It would be helpful to know your feelings about them (are they fundamental? can they be dropped? etc.). The aim here is to understand if we can eventually come up with a sched-upstream branch that is more easily applicable on top of the Juno integration branch:
http://git.linaro.org/landing-teams/working/arm/kernel.git integration-lsk-3.10-juno-android
I'll try to give you a list of patches that I had to remove or revert from sched-upstream when trying to build a branch that supports Juno and has EASv3 on top (so that we could test it on Android). I'll also add comments about patches that I'm more familiar with. Please be aware that I had to come up with this in quite a hurry, as we wanted to show EAS results coming from Juno at the last Connect. This means that the rationale for deciding to keep or drop a patch in the branch was merely "drop everything that seems to have non trivial conflicts". At the end I was fairly happy with the behaviours, but this doesn't necessarily mean that we still not need some of what I dropped.
080bdd1 exit.c: unexport __set_special_pids() cdba026 ptrace: revert "Prepare to fix racy accesses on task breakpoints" 73bcb2e mm: remove free_area_cache 802d8c2 ptrace/x86: revert "hw_breakpoints: Fix racy access to ptrace breakpoints" 6472001 ptrace/arm: revert "hw_breakpoints: Fix racy access to ptrace breakpoints"
f0a709a sched: Add new scheduler syscalls to support an extended scheduling parameters ABI 631db36 sched/core: Fix htmldocs warnings 4f89001 sched: Preserve the nice level over sched_setscheduler() and sched_setparam() calls c9d415b sched: Fix up scheduler syscall LTP fails 0525ffc sched: Fix up attr::sched_priority warning b62aed3 sched: Move SCHED_RESET_ON_FORK into attr::sched_flags 7d214b1 sched: Fix __sched_setscheduler() nice test 9db9c75 sched: Fix information leak in sys_sched_getattr() 10d4f89 sched: Add 'flags' argument to sched_{set,get}attr() syscalls
as this preceding set comes with the (or are subsequent fixes of) the SCHED_DEADLINE patchset, I think we could just ignore them for now
That's ok to remove them.
02fee98 ARM: introduce common set_auxcr/get_auxcr functions
6a4f9e7 sched: Implement task_nice() as static inline function
this preceding patch is maybe not a crucial fix?
6261e04 sched: Adjust p->sched_reset_on_fork when nothing else changes
This one seems a function fix. Could we keep this one?
I guess yes, this should be easily applied even without the previous commit actually.
33e8006 sched: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE
this two preceding patches depend on 6a4f9e7
It's ok to remove above commits.
15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints
Did preceding commits' function support in juno tree, or they were replaced by other commits? Is juno cpuidle driver happy without them?
As said, I'm not sure about the previous commits. What I can say is that EAS behaviours looked good in the end (even idle paths), but I can't unfortunately tell if some of these are still fundamental.
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu()
Above commits are related with performance&power when system has more clusters. remove them may cuase perf/power issue in some cases.
Ok, I guess we might want to spend some more time fixing these conflicts then.
And finally apply the attached patches to make the branch compile.
They're ok.
Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :).
Hi Juri,
What's cause conflict with about commits, HMP or some android sched change? Looks few of commit can be clean up, like deadline related.
So, we don't have HMP here as it has been removed from the integration branch. I'm not sure if we have Android sched specific changes in the branch, though. Are you aware of any in particular?
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
Thanks for your comments.
Best,
- Juri
On 04/29/2015 02:47 AM, Juri Lelli wrote:
15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints
Did preceding commits' function support in juno tree, or they were replaced by other commits? Is juno cpuidle driver happy without them?
As said, I'm not sure about the previous commits. What I can say is that EAS behaviours looked good in the end (even idle paths), but I can't unfortunately tell if some of these are still fundamental.
If cpuidle works well, it's ok to remove them. Just most of preceding commits are related with IPI, a bit concern on the following IPI commits picking up. If no, removing is ok.
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu()
Above commits are related with performance&power when system has more clusters. remove them may cuase perf/power issue in some cases.
Ok, I guess we might want to spend some more time fixing these conflicts then.
And finally apply the attached patches to make the branch compile.
They're ok.
Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :).
Hi Juri,
What's cause conflict with about commits, HMP or some android sched change? Looks few of commit can be clean up, like deadline related.
So, we don't have HMP here as it has been removed from the integration branch. I'm not sure if we have Android sched specific changes in the branch, though. Are you aware of any in particular?
Didn't try to figure out that since HMP is in lsk-android.
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
Thanks for your comments.
On Wed, Apr 29, 2015 at 8:48 AM, Alex Shi alex.shi@linaro.org wrote:
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
We need to backport platform-specific patches only for a few platforms for which we have hardware for testing. Let us skip all other platforms.
Hi Amit,
On 29/04/15 06:16, Amit Kucheria wrote:
On Wed, Apr 29, 2015 at 8:48 AM, Alex Shi alex.shi@linaro.org wrote:
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
We need to backport platform-specific patches only for a few platforms for which we have hardware for testing. Let us skip all other platforms.
And we still keep these patches in sched-upstream?
Thanks,
- Juri
On Wed, Apr 29, 2015 at 3:50 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 29/04/15 06:16, Amit Kucheria wrote:
On Wed, Apr 29, 2015 at 8:48 AM, Alex Shi alex.shi@linaro.org wrote:
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
We need to backport platform-specific patches only for a few platforms for which we have hardware for testing. Let us skip all other platforms.
And we still keep these patches in sched-upstream?
Not necessarily. We could put them under stable/platform-support or something similar to avoid mixing it with the platform-agnostic scheduler patches.
On 29/04/15 14:17, Amit Kucheria wrote:
On Wed, Apr 29, 2015 at 3:50 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 29/04/15 06:16, Amit Kucheria wrote:
On Wed, Apr 29, 2015 at 8:48 AM, Alex Shi alex.shi@linaro.org wrote:
> But as to arch/cpuidle related part, don't know if other SoC happy to > miss them? >
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
We need to backport platform-specific patches only for a few platforms for which we have hardware for testing. Let us skip all other platforms.
And we still keep these patches in sched-upstream?
Not necessarily. We could put them under stable/platform-support or something similar to avoid mixing it with the platform-agnostic scheduler patches.
Ok, this makes sense to me. It looks more maintainable.
Thanks,
- Juri
Thanks Alex
On 04/29/2015 09:46 PM, Juri Lelli wrote:
On 29/04/15 14:17, Amit Kucheria wrote:
On Wed, Apr 29, 2015 at 3:50 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 29/04/15 06:16, Amit Kucheria wrote:
On Wed, Apr 29, 2015 at 8:48 AM, Alex Shi alex.shi@linaro.org wrote:
>> But as to arch/cpuidle related part, don't know if other SoC happy to >> miss them? >> So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
We need to backport platform-specific patches only for a few platforms for which we have hardware for testing. Let us skip all other platforms.
And we still keep these patches in sched-upstream?
Not necessarily. We could put them under stable/platform-support or something similar to avoid mixing it with the platform-agnostic scheduler patches.
yes, the like named the juno support like, stable/platform-support/juno
Ok, this makes sense to me. It looks more maintainable.
Thanks,
- Juri
On 29/04/15 04:18, Alex Shi wrote:
On 04/29/2015 02:47 AM, Juri Lelli wrote:
15bfe13 arm64: use common reboot infrastructure 52cefcb arm64: Fix definition of arm_pm_restart to match the declaration 8c7b4f7 arm64: kernel: add CPU idle call e1bf4b0 time: Change the return type of clockevents_notify() to integer ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled 2e576ce tracepoint: add generic tracepoint definitions for IPI tracing 5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs 128647d ARM: SMP: basic IPI triggered completion support eccd85f ARM: add IPI tracepoints 5be433d arm64: enable generic clockevent broadcast e947689 arm64: Support arch_irq_work_raise() via self IPIs 5716acb ARM64: add IPI tracepoints
Did preceding commits' function support in juno tree, or they were replaced by other commits? Is juno cpuidle driver happy without them?
As said, I'm not sure about the previous commits. What I can say is that EAS behaviours looked good in the end (even idle paths), but I can't unfortunately tell if some of these are still fundamental.
If cpuidle works well, it's ok to remove them. Just most of preceding commits are related with IPI, a bit concern on the following IPI commits picking up. If no, removing is ok.
From what I can tell, we need 5174675 "ARM: 7872/1: Support
arch_irq_work_raise() via self IPIs" and e947689 "arm64: Support arch_irq_work_raise() via self IPIs" if we are going to use irq_work stuff for sched_dvfs.
Thanks,
- Juri
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI 50299a0 sched/idle: Avoid spurious wakeup IPIs 7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups 95ec016 sched/idle: Simplify wake_up_idle_cpu()
Above commits are related with performance&power when system has more clusters. remove them may cuase perf/power issue in some cases.
Ok, I guess we might want to spend some more time fixing these conflicts then.
And finally apply the attached patches to make the branch compile.
They're ok.
Please don't hesitate to ask for more information, as I understand that all this might be quite confusing :).
Hi Juri,
What's cause conflict with about commits, HMP or some android sched change? Looks few of commit can be clean up, like deadline related.
So, we don't have HMP here as it has been removed from the integration branch. I'm not sure if we have Android sched specific changes in the branch, though. Are you aware of any in particular?
Didn't try to figure out that since HMP is in lsk-android.
But as to arch/cpuidle related part, don't know if other SoC happy to miss them?
So, IMHO, we shouldn't have arch specific code in the sched-upstream branch. Arch specific code should instead reside in some other branch and get integrated only when putting all together. Do you think we can work towards this solution? Or am I missing something?
I agree with you on this. Just most of arch related commits are due to cpuidle/cpufreq driver. or may few of them could be removed. I will more care about this in future backporting. But to be aware, that can't be removed totally, considering to pass initial boot testing.
Thanks for your comments.
-
Alex Shi -
Amit Kucheria -
Juri Lelli