Hi Andrey,
Below is pull request for v7 of MP work, you can skip v6-resend pull request that i sent yesterday. Following are the main changes: - Based on v3.6-rc3 - per-task-load-average updated with v3 - applied Tixy's patch from fast-slow-cpu-dt-v1 to task-placement-v1 as they are somewhat related only. And so removed fast-slow-cpu-dt-v1 branch
NOTE: Compile tested only
-- viresh
--------------->8-----------------------------
The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0:
Linux 3.6-rc3 (2012-08-22 13:29:06 -0700)
are available in the git repository at:
git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-v7
for you to fetch changes up to 549b2d49de89f9454a933a32efb5825a076efd42:
Merge branches 'per-cpu-thread-hotplug-v3-fixed', 'task-placement-v1', 'cpu-hotplug-get_online_cpus-v1', 'arm-asymmetric-support-v3-v3.6-rc1' and 'config-fragments' into big-LITTLE-MP-v7 (2012-08-24 09:24:14 +0530)
----------------------------------------------------------------
Ben Segall (1): sched: maintain per-rq runnable averages
Jon Medhurst (6): configs: Initial core configs configs: Make CONFIG_MODULES part of linaro-base Merge branch 'config-core-3.4' into config-core-tracking configs: Replace CONFIG_PERF_COUNTERS with CONFIG_PERF_EVENTS configs: android: Enable FB_EARLYSUSPEND configs: android: Enable CONFIG_INPUT_UINPUT to get aidb working
Jon Medhurst (Tixy) (1): sched: Use device-tree to provide fast/slow CPU list for HMP
Morten Rasmussen (6): sched: Add ftrace events for entity load-tracking sched: entity load-tracking load_avg_ratio sched: load-tracking driven wakeup migration for HMP platforms sched: Forced migration of high load task on HMP platforms sched: Add HMP forced task migration ftrace event sched: Add missing cpus_allowed checks to HMP scheduler
Paul E. McKenney (2): rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread hotplug: Fix UP bug in smpboot hotplug code
Paul Turner (15): sched: track the runnable average on a per-task entitiy basis sched: aggregate load contributed by task entities on parenting cfs_rq sched: maintain the load contribution of blocked entities sched: add an rq migration call-back to sched_class sched: account for blocked load waking back up sched: aggregate total task_group load sched: compute load contribution by a group entity sched: normalize tg load contributions against runnable time sched: maintain runnable averages across throttled periods sched: replace update_shares weight distribution with per-entity computation sched: refactor update_shares_cpu() -> update_blocked_avgs() sched: update_cfs_shares at period edge sched: make __update_entity_runnable_avg() fast sched: implement usage tracking sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking
Ricardo Salveti de Araujo (8): configs: moving previous ubuntu.conf as ubuntu-minimal and creating a full ubuntu one configs: ubuntu: be compatible with the enforce script configs: ubuntu: disabling CODA_FS, seems to be broken atm configs: ubuntu: disabling CGROUPS as default Merge branch 'config-core-3.4' into config-core-tracking configs: ubuntu: updating configs for 3.5 configs: ubuntu: disabling CONFIG_MTD_NAND_NANDSIM=m, breaking build config: ubuntu: ATH6KL should be platform dependent
Silas Boyd-Wickizer (4): Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug
Thomas Gleixner (6): rcu: Yield simpler kthread: Implement park/unpark facility smpboot: Provide infrastructure for percpu hotplug threads softirq: Use hotplug thread infrastructure watchdog: Use hotplug thread infrastructure infiniband: ehca: Use hotplug thread infrastructure
Vincent Guittot (1): sched: cpu_power: enable ARCH_POWER
Viresh Kumar (3): configs: Add config fragments for big LITTLE MP linaro/configs: Update big LITTLE MP fragment for task placement work Merge branches 'per-cpu-thread-hotplug-v3-fixed', 'task-placement-v1', 'cpu-hotplug-get_online_cpus-v1', 'arm-asymmetric-support-v3-v3.6-rc1' and 'config-fragments' into big-LITTLE-MP-v7
arch/arm/Kconfig | 29 + arch/arm/kernel/topology.c | 69 ++ arch/x86/kernel/cpuid.c | 5 + arch/x86/kernel/msr.c | 5 + drivers/hwmon/coretemp.c | 5 + drivers/hwmon/via-cputemp.c | 5 + drivers/infiniband/hw/ehca/ehca_irq.c | 253 ++-- drivers/infiniband/hw/ehca/ehca_irq.h | 6 +- include/linux/kthread.h | 11 +- include/linux/sched.h | 24 + include/linux/smpboot.h | 43 + include/trace/events/sched.h | 151 +++ kernel/Makefile | 3 +- kernel/cpu.c | 10 +- kernel/kthread.c | 185 ++- kernel/rcutree.c | 12 +- kernel/rcutree.h | 15 +- kernel/rcutree_plugin.h | 403 ++----- kernel/rcutree_trace.c | 3 +- kernel/sched/core.c | 11 + kernel/sched/debug.c | 39 +- kernel/sched/fair.c | 1111 ++++++++++++++--- kernel/sched/features.h | 2 +- kernel/sched/sched.h | 60 +- kernel/smpboot.c | 233 ++++ kernel/smpboot.h | 4 + kernel/softirq.c | 108 +- kernel/watchdog.c | 263 ++-- linaro/configs/android.conf | 33 + linaro/configs/big-LITTLE-MP.conf | 9 + linaro/configs/linaro-base.conf | 84 ++ linaro/configs/ubuntu-minimal.conf | 24 + linaro/configs/ubuntu.conf | 2133 +++++++++++++++++++++++++++++++++ 33 files changed, 4355 insertions(+), 996 deletions(-) create mode 100644 include/linux/smpboot.h create mode 100644 linaro/configs/android.conf create mode 100644 linaro/configs/big-LITTLE-MP.conf create mode 100644 linaro/configs/linaro-base.conf create mode 100644 linaro/configs/ubuntu-minimal.conf create mode 100644 linaro/configs/ubuntu.conf
On Fri, 2012-08-24 at 10:32 +0530, Viresh Kumar wrote:
Hi Andrey,
Below is pull request for v7 of MP work, you can skip v6-resend pull request that i sent yesterday. Following are the main changes: - Based on v3.6-rc3 - per-task-load-average updated with v3 - applied Tixy's patch from fast-slow-cpu-dt-v1 to task-placement-v1 as they are somewhat related only. And so removed fast-slow-cpu-dt-v1 branch
NOTE: Compile tested only
Is this critical for this month's release? The release candidate builds are possibly already in testing so we would have to request that they are stopped and redone?
On 24 August 2012 12:32, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Is this critical for this month's release? The release candidate builds are possibly already in testing so we would have to request that they are stopped and redone?
Not sure, what is fixed in this version? Maybe Morten can tell if anything crucial for task placement work is there or not.
https://lkml.org/lkml/2012/8/23/267
I just noticed a new version and applied it. Can be pulled in later if there is nothing very important in it.
-- viresh
On Fri, Aug 24, 2012 at 12:37 PM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 24 August 2012 12:32, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Is this critical for this month's release? The release candidate builds are possibly already in testing so we would have to request that they are stopped and redone?
Not sure, what is fixed in this version? Maybe Morten can tell if anything crucial for task placement work is there or not.
https://lkml.org/lkml/2012/8/23/267
I just noticed a new version and applied it. Can be pulled in later if there is nothing very important in it.
Viresh,
While our goal is to keep track of the bleeding edge, and I think you're doing a great job there, let's figure out a plan to minimise the number of kernel releases we make.
Can you look at your previous 6 releases and their dates and figure out if it would be ok to do only 2 releases a month? Were there urgent bug fixes that need to be fed in, or was it just new revs of the patchsets? If the former, then making immediate releases is the best course, if the latter, perhaps we can batch up all changes and make a release on predictable dates - say 1st and 15th of every month. This will lighten the load for everyone concerned: you, Andrey, build team with one downside: integration problems will not get detected until late.
I'd like to hear your views.
Regards, Amit
On 24 August 2012 14:49, Amit Kucheria amit.kucheria@linaro.org wrote:
While our goal is to keep track of the bleeding edge, and I think you're doing a great job there, let's figure out a plan to minimise the number of kernel releases we make.
Can you look at your previous 6 releases and their dates and figure out if it would be ok to do only 2 releases a month? Were there urgent bug fixes that need to be fed in, or was it just new revs of the patchsets? If the former, then making immediate releases is the best course, if the latter, perhaps we can batch up all changes and make a release on predictable dates - say 1st and 15th of every month. This will lighten the load for everyone concerned: you, Andrey, build team with one downside: integration problems will not get detected until late.
I'd like to hear your views.
Hi Amit,
Following are the dates when I have published releases:
V1 - 4th July V2 - 11 July V3 - 16 July V4 - 25 July V4 (resend) - 26 July: Patches requested by Paul E. McKenney V5 - 14 Aug V6 - 17 Aug - removed Vincent's patch V6 (resend) - 23 Aug - Vincent's patch again required :) V7 - 24 Aug
Most of the times, release were due to: - New branch/topic - New Version of earlier patchset - Sometime fixes
Till now, the stats are pretty ugly :( Mostly because of the cases, where i just publish a version and somebody asks me to include/exclude something. That makes the resend versions found above.
I would like to go for 5th and 20th of every month, as 20th is a bit close to WG freeze date for the month.
In the mean time, for whatever updates we have, I will create the next version branch and publish it. But will not send a pull request for it.
How does that sound to you guys?
-- viresh
On Fri, 2012-08-24 at 15:10 +0530, Viresh Kumar wrote:
On 24 August 2012 14:49, Amit Kucheria amit.kucheria@linaro.org wrote: While our goal is to keep track of the bleeding edge, and I think you're doing a great job there, let's figure out a plan to minimise the number of kernel releases we make.
I would like to go for 5th and 20th of every month, as 20th is a bit close to WG freeze date for the month.
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
With fixed dates, the 20th of next month is the Thurday before the release, i.e. the day on which kernel changes are frozen, and the 20th of October is is just after the release candidate builds will have started.
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
Even better.
-- viresh
On 24 August 2012 07:12, Viresh Kumar viresh.kumar@linaro.org wrote:
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
Even better.
+1
-- viresh
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
Hi Guys,
I have updated
https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTre...
as per our last discussion. Please see if i have missed something.
-- viresh
On Mon, Aug 27, 2012 at 10:07 PM, Viresh Kumar viresh.kumar@linaro.org wrote:
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
Hi Guys,
I have updated
https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTre...
as per our last discussion. Please see if i have missed something.
Looks good to me. Thanks.
/Amit
On Tue, 2012-08-28 at 10:37 +0530, Viresh Kumar wrote:
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
Hi Guys,
I have updated
https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTre...
as per our last discussion. Please see if i have missed something.
Look good.
Thanks.
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
With fixed dates, the 20th of next month is the Thurday before the release, i.e. the day on which kernel changes are frozen, and the 20th of October is is just after the release candidate builds will have started.
Hi guys,
Sorry for replying on a very old mail :( Dates are a bit modified after the last request from Andrey. The final pull request for month release would be made on:
* Friday before Kernel WG Freeze week
So that Andrey and LT's get enough time to test releases. Also update here:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTre...
-- viresh
On Wed, 2012-10-17 at 14:18 +0530, Viresh Kumar wrote:
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed dates each month the should probably be tied to the release dates. E.g. the Monday of the week before release (the normal WG cut-of date), and two weeks before (or after?) that?
With fixed dates, the 20th of next month is the Thurday before the release, i.e. the day on which kernel changes are frozen, and the 20th of October is is just after the release candidate builds will have started.
Hi guys,
Sorry for replying on a very old mail :( Dates are a bit modified after the last request from Andrey. The final pull request for month release would be made on:
- Friday before Kernel WG Freeze week
So that Andrey and LT's get enough time to test releases.
Sounds good. (On Friday I started composing a mail with the same suggestion but you sent out the MP branch pull request whilst I was writing it so I didn't send it in the end.)
Sorry guys - can I get this proposal straight in my head?
12.11 release - 29/11 Platforms close - 22/11 Kernel close - 15/11 MP close - 08/11
I understand the week of testing for the platforms team. I understand a week prior to that for testing within the kernel team.
What is happening between MP close and Kernel close that requires an additional weeks testing?
Thanks,
Steve
-----Original Message----- From: Jon Medhurst (Tixy) [mailto:tixy@linaro.org] Sent: 17 October 2012 10:30 To: Viresh Kumar Cc: Amit Kucheria; Lists linaro-dev; Steve Bannister; Morten Rasmussen; Andrey Konovalov Subject: Re: [GIT PULL] bit-LITTLE-MP-v7
On Wed, 2012-10-17 at 14:18 +0530, Viresh Kumar wrote:
On 24 August 2012 16:39, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Sounds OK from my point of view, except that rather than fixed
dates
each month the should probably be tied to the release dates. E.g.
the
Monday of the week before release (the normal WG cut-of date), and
two
weeks before (or after?) that?
With fixed dates, the 20th of next month is the Thurday before the release, i.e. the day on which kernel changes are frozen, and the
20th
of October is is just after the release candidate builds will have started.
Hi guys,
Sorry for replying on a very old mail :( Dates are a bit modified after the last request from Andrey. The
final
pull request for month release would be made on:
- Friday before Kernel WG Freeze week
So that Andrey and LT's get enough time to test releases.
Sounds good. (On Friday I started composing a mail with the same suggestion but you sent out the MP branch pull request whilst I was writing it so I didn't send it in the end.)
-- Tixy
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 18 October 2012 22:42, Steve Bannister Steve.Bannister@arm.com wrote:
Sorry guys - can I get this proposal straight in my head?
12.11 release - 29/11 Platforms close - 22/11 Kernel close - 15/11 MP close - 08/11
I understand the week of testing for the platforms team. I understand a week prior to that for testing within the kernel team.
What is happening between MP close and Kernel close that requires an additional weeks testing?
This is what Andrey earlier said on this:
From Andrey:
-----------------
I just wanted to give the LTs some time to move their linux-linaro (ll) topics to the updated linux-linaro-core-tracking (llct) tree: * Friday, October 12 evening: llct is updated * Monday, October 15 morning to Tuesday, October 16 evening (some European time; which corresponds to morning PST): couple days for the LTs to rebase their topics and verify the result * Tuesday, October 16 evening (some European time): updated linux-linaro tree (the 12.10 release candidate) is pushed to git * Wednesday, October 17 morning to Thursday, October 18 evening: couple days to validate the ll tree in ci tests, fix the possible issues. * Thursday, October 18 evening: linux-linaro kernel release.
Pulling the topics on Monday would leave one full day at most (less in case of very different timezones) for the LTs to prepare their linux-linaro topics. Guess this would be too tight schedule for them.
-- viresh
That's the justification for closing the week before the release of the llct. What I'm asking is why we're now closing the MP branch 2 weeks before that.
The proposed date of the 9th Nov is a full 3 weeks before the release on the 29th Nov. Working back from the release date that's one week for platform level testing, one week for the LT work described by Andrey, and the third week is for what? I'm happy if there's a good reason but it's not clear to me what it is.
Cheers,
Steve
On 18 Oct 2012, at 18:17, Viresh Kumar viresh.kumar@linaro.org wrote:
On 18 October 2012 22:42, Steve Bannister Steve.Bannister@arm.com wrote:
Sorry guys - can I get this proposal straight in my head?
12.11 release - 29/11 Platforms close - 22/11 Kernel close - 15/11 MP close - 08/11
I understand the week of testing for the platforms team. I understand a week prior to that for testing within the kernel team.
What is happening between MP close and Kernel close that requires an additional weeks testing?
This is what Andrey earlier said on this:
From Andrey:
I just wanted to give the LTs some time to move their linux-linaro (ll) topics to the updated linux-linaro-core-tracking (llct) tree:
- Friday, October 12 evening: llct is updated
- Monday, October 15 morning to Tuesday, October 16 evening (some
European time; which corresponds to morning PST): couple days for the LTs to rebase their topics and verify the result
- Tuesday, October 16 evening (some European time): updated
linux-linaro tree (the 12.10 release candidate) is pushed to git
- Wednesday, October 17 morning to Thursday, October 18 evening:
couple days to validate the ll tree in ci tests, fix the possible issues.
- Thursday, October 18 evening: linux-linaro kernel release.
Pulling the topics on Monday would leave one full day at most (less in case of very different timezones) for the LTs to prepare their linux-linaro topics. Guess this would be too tight schedule for them.
-- viresh
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 18 October 2012 23:06, Steve Bannister Steve.Bannister@arm.com wrote:
That's the justification for closing the week before the release of the llct. What I'm asking is why we're now closing the MP branch 2 weeks before that.
Because i misread: https://wiki.linaro.org/Cycles :(
I thought that the date of kernel WG freeze is: November 15th, which actually is 22nd.
So I am moving date of MP release to 16th.
Sorry for the noise.
-- viresh
-
Amit Kucheria -
David Zinman -
Jon Medhurst (Tixy) -
Steve Bannister -
Viresh Kumar