[GIT PULL] big LITTLE MP - v16
Hi Andrey, Sorry for being late this time. Were waiting for Android tree to become available for doing testing. big LITTLE MP v15 is ready for you to pull. Updates: --- - Rebased over 3.9-rc2 - Stats: Total distinct patches: 33 - Dropped Patches: - cpufreq-fixes-v3 branch, already upstreamed. - hw-bkp-v7.1-debug-v2 branch, already upstreamed, one new fix included though. -x---x The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-master-v16 for you to fetch changes up to e695239d5f0a553e28a1ff5f346fcc3fafab2b2f: Merge branch 'master-hw-bkpt-fix' into big-LITTLE-MP-master-v16 (2013-03-20 19:53:24 +0530) Chris Redpath (2): ARM: Experimental Frequency-Invariant Load Scaling Patch ARM: Fix build breakage when big.LITTLE.conf is not used. Jon Medhurst (1): ARM: sched: Avoid empty 'slow' HMP domain Liviu Dudau (1): linaro/configs: big-LITTLE-MP: Enable the new tunable sysfs interface by default. Lokesh Vutla (1): ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr' Lorenzo Pieralisi (1): ARM: kernel: provide cluster to logical cpu mask mapping API Morten Rasmussen (14): sched: entity load-tracking load_avg_ratio sched: Task placement for heterogeneous systems based on task load-tracking sched: Forced task migration on heterogeneous systems sched: Introduce priority-based task migration filter ARM: Add HMP scheduling support for ARM architecture ARM: sched: Use device-tree to provide fast/slow CPU list for HMP ARM: sched: Setup SCHED_HMP domains sched: Add ftrace events for entity load-tracking sched: Add HMP task migration ftrace event sched: SCHED_HMP multi-domain task migration control sched: Enable HMP priority filter by default sched: Only down migrate low priority tasks if allowed by affinity mask linaro/configs: Enable HMP priority filter by default sched: Basic global balancing support for HMP Olivier Cozette (1): ARM: Change load tracking scale using sysfs Paul Turner (1): sched: implement usage tracking Sudeep KarkadaNagesha (7): ARM: perf: replace global CPU PMU pointer with per-cpu pointers ARM: perf: register CPU PMUs with idr types ARM: perf: set cpu affinity to support multiple PMUs ARM: perf: set cpu affinity for the irqs correctly ARM: perf: remove spaces in CPU PMU names ARM: perf: save/restore pmu registers in pm notifier sched: fix arch_get_fast_and_slow_cpus to get logical cpumask correctly Thomas Gleixner (1): genirq: Add default affinity mask command line option Viresh Kumar (5): configs: Add config fragments for big LITTLE MP linaro/configs: Update big LITTLE MP fragment for task placement work config-frag/big-LITTLE: Use device-tree to provide fast/slow CPU list for HMP Merge branches 'arm-multi_pmu_v2', 'task-placement-v2-sysfs', 'misc-patches' and 'config-fragments' into big-LITTLE-MP-master-v16 Merge branch 'master-hw-bkpt-fix' into big-LITTLE-MP-master-v16 Documentation/devicetree/bindings/arm/pmu.txt |3 + Documentation/kernel-parameters.txt |9 + arch/arm/Kconfig | 85 ++ arch/arm/include/asm/pmu.h| 12 + arch/arm/include/asm/topology.h | 34 + arch/arm/kernel/hw_breakpoint.c |3 +- arch/arm/kernel/perf_event.c | 19 + arch/arm/kernel/perf_event_cpu.c | 117 ++- arch/arm/kernel/perf_event_v7.c | 57 +- arch/arm/kernel/topology.c| 132 include/linux/sched.h | 12 + include/trace/events/sched.h | 153 kernel/irq/irqdesc.c | 21 +- kernel/sched/core.c |4 + kernel/sched/debug.c |3 + kernel/sched/fair.c | 1021 - kernel/sched/sched.h | 13 +- linaro/configs/big-LITTLE-MP.conf | 13 + 18 files changed, 1663 insertions(+), 48 deletions(-) create mode 100644 linaro/configs/big-LITTLE-MP.conf ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
Quoting Bill Huang (2013-03-19 21:39:44) > On Wed, 2013-03-20 at 11:31 +0800, Mike Turquette wrote: > > Quoting Bill Huang (2013-03-19 19:55:49) > > > On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote: > > > > Quoting Bill Huang (2013-03-19 06:28:32) > > > > > Add notifier calls in clk_prepare and clk_unprepare so drivers which > > > > > are > > > > > interested in knowing that clk_prepare/unprepare call can act > > > > > accordingly. > > > > > > > > > > The existing "clk_set_rate" notifier is not enough for normal DVFS > > > > > inplementation since clock might be enabled/disabled at runtime. > > > > > Adding > > > > > these notifiers is useful on DVFS core which take clk_prepare as a > > > > > hint > > > > > on that the notified clock might be enabled later so it can raise > > > > > voltage > > > > > to a safe level before enabling the clock, and take clk_unprepare as a > > > > > hint that the clock has been disabled and is safe to lower the > > > > > voltage. > > > > > > > > > > The added notifier events are: > > > > > > > > > > PRE_CLK_PREPARE > > > > > POST_CLK_PREPARE > > > > > ABORT_CLK_PREPARE > > > > > PRE_CLK_UNPREPARE > > > > > POST_CLK_UNPREPARE > > > > > > > > > > Signed-off-by: Bill Huang > > > > > > > > I'm still not sure about this approach. Based on feedback I got from > > > > Linaro Connect I am not convinced that scaling voltage through clk > > > > rate-change notifiers is the right way to go. As I understand it this > > > > patch only exists for that single purpose, so if the voltage-notifier > > > > idea gets dropped then I will not take this patch in. > > > > > > > Thanks Mike, actually we won't use your "clk: notifier handler for > > > dynamic voltage scaling" patch instead we are trying to port our DVFS > > > into Non-CPU DVFS framework "devfreq" which will need to hook those > > > notifiers, without the clock notifiers been extended the framework is > > > useless for us since we cannot do polling due to the fact that polling > > > is not in real time. If it ended up extending the notifiers cannot > > > happen then the only choice for us I think would be giving up "devfreq" > > > and implement them in Tegra's "clk_hw". > > > > I'm familiar with the devfreq framework. Can you explain further how > > you plan to use devfreq with the clock notifiers? What does the call > > graph look like? > > > The call graph will look like this, when any DVFS interested clock rate > changes (including enable and disable) happen -> Tegra devfreq clock > notifier is called -> call into update_devfreq if needed -> in > update_devfreq it will call into .get_target_freq in Tegra > "devfreq_governor" -> and then call into .target of tegra > devfreq_dev_profile to set voltage and done. More details are as below. > > We'll create devfreq driver for Tegra VDD_CORE rail, and the safe > voltage level of the rail is determined by tens of clocks (2d, 3d, > mpe,...), all the frequency ladders of those clocks are defined in DT > also the operating points for VDD_CORE is declared in DT where its > frequency will be more of a virtual clock or index. > > operating-points = < > /* virtual-kHz uV */ > 0 95 > 1 100 > 2 105 > 3 110 > 4 115 > 5 120 > 6 125 > 7 130 > 8 135 > > Register a Tegra governor where the callback .get_target_freq is the > function to determine the overall frequency it can go to, and > the .target callback in "devfreq_dev_profile" will be the function > really do the voltage scaling. > > Tegra devfreq driver will register clock notifiers on all its interested > clock and hence when any of those clock rate changes, disabled, enabled, > we'll specifically call update_devfreq in the notifier. Thank you for the explanation. Do you plan to use actual devfreq governors (like simple-ondemand, or something custom) for changing OPPs, or do you just plan to use the clock framework as a trigger for DVFS? Regards, Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 Resend 4/4] timer: Migrate running timer
On 27 November 2012 19:17, Steven Rostedt wrote:
> On Tue, 2012-11-06 at 16:08 +0530, Viresh Kumar wrote:
>> diff --git a/kernel/timer.c b/kernel/timer.c
>> @@ -729,6 +730,12 @@ __mod_timer(struct timer_list *timer, unsigned long
>> expires,
>>
>> base = lock_timer_base(timer, &flags);
>>
>> + if (timer->sched_del) {
>> + /* Don't schedule it again, as it is getting deleted */
>> + ret = -EBUSY;
>> + goto out_unlock;
>> + }
>> +
>> ret = detach_if_pending(timer, base, false);
>> if (!ret && pending_only)
>> goto out_unlock;
>> @@ -746,21 +753,12 @@ __mod_timer(struct timer_list *timer, unsigned long
>> expires,
>> new_base = per_cpu(tvec_bases, cpu);
>>
>> if (base != new_base) {
>> - /*
>> - * We are trying to schedule the timer on the local CPU.
>> - * However we can't change timer's base while it is running,
>> - * otherwise del_timer_sync() can't detect that the timer's
>> - * handler yet has not finished. This also guarantees that
>> - * the timer is serialized wrt itself.
>> - */
>> - if (likely(base->running_timer != timer)) {
>> - /* See the comment in lock_timer_base() */
>> - timer_set_base(timer, NULL);
>> - spin_unlock(&base->lock);
>> - base = new_base;
>> - spin_lock(&base->lock);
>> - timer_set_base(timer, base);
>> - }
>> + /* See the comment in lock_timer_base() */
>> + timer_set_base(timer, NULL);
>> + spin_unlock(&base->lock);
>> + base = new_base;
>> + spin_lock(&base->lock);
>> + timer_set_base(timer, base);
>> }
> I don't think this is good enough. For one thing, it doesn't handle
> try_to_del_timer_sync() or even del_timer_sync() for that matter. As
> that may return success when the timer happens to be running on another
> CPU.
>
> We have this:
>
> CPU0CPU1
>
>timerA (running)
>mod_timer(timerA)
>[ migrate to CPU2 ]
>release timer base lock
>del_timer_sync(timerA)
>timer->sched_del = true
>try_to_del_timer_sync(timerA)
> base(CPU2)->timer != timerA
> [TRUE!]
> timerA (finishes)
>
> Fail!
Hi Steven/Thomas,
I came back to this patch after completing some other stuff and posting
wq part of this patchset separately.
I got your point and understand how this would fail.
@Thomas: I need your opinion first. Do you like this concept of migrating
running timer or not? Or you see some basic problem with this concept?
If no (i.e. i can go ahead with another version), then i have some solution to
fix earlier problems reported by Steven:
The problem lies with del_timer_sync() which just checks
base->running_timer != timer to check if timer is currently running or not.
What if we add another variable in struct timer_list, that will store if we are
running timer callback or not. And so, before we call callback in timer core,
we will set this variable and will reset it after finishing callback.
del_timer_sync() will have something like:
if (base->running_timer != timer)
remove timer and return;
else if (timer->running_callback)
go back to its loop...
So, with my existing patch + this change, del_timer_sync() will not return
back unless the callback is completed on CPU0.
But what can happen now is base->running_timer == timer can be true
for two cpus simultaneously cpu0 (running callback) and cpu2 (running hardware
timer). Will that cause any issues?
--
viresh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
big.LITTLE MP status Mar 20, 2013
https://wiki.linaro.org/projects/big.LITTLE.MP Work Items for functional completion: https://wiki.linaro.org/projects/big.LITTLE.MP/WorkItems Roadmap Cards: Improving HMP Linux scheduling - http://cards.linaro.org/browse/CARD-190 Blueprints and bugs are all now in a single Launchpad project for big.LITTLE: https://launchpad.net/linaro-big-little-system Development = Version 16 of big.LITTLE MP has been pulled: Updates: --- - Rebased over 3.9-rc2 - Stats: Total distinct patches: 33 - Dropped Patches: - cpufreq-fixes-v3 branch, already upstreamed. - hw-bkp-v7.1-debug-v2 branch, already upstreamed, one new fix included though. http://lists.linaro.org/pipermail/linaro-dev/2013-March/015684.html Blueprint Update - * https://blueprints.launchpad.net/linaro-big-little-system/+spec/cpuidle-add-cpu-specific-states-capability * Upstreamed, waiting for the TC2 drivers to be upstreamed * cpuidle - rework the refcounting mechanism : TODO: will not be done this month * https://blueprints.launchpad.net/linaro-big-little-system/+spec/sched-cooperation-with-dvfs-and-idling * not started * scheduled for April, but probably unrealistic * ACTION: Expedite * https://blueprints.launchpad.net/linaro-big-little-system/+spec/small-task-packing-in-scheduler * will upstream for review this week * https://blueprints.launchpad.net/linaro-big-little-system/+spec/hotplug-performance-testing * TBD QA === big.LITTLE MP LAVA Dashboard http://validation.linaro.org/lava-server/dashboard/image-reports/linaro-android_vexpress-linaro-mp Testing: # of Cases # Run PassFail Absolute pass rate Regression 20 19 19 0 100 mpbasicsuite10 9 9 1 90 mpcoresuite 4 4 4 0 75 mpextendedsuite 6 6 4 2 66.7 mploadbalance 2 2 2 0 100 http://lists.linaro.org/pipermail/linaro-dev/2013-March/015673.html Bugs: https://bugs.launchpad.net/linaro-big-little-system/+bugs?field.tag=bl-mp -- David Zinman, Project Manager Linaro.org | Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
On 20 March 2013 15:47, Mike Turquette wrote: > Quoting Bill Huang (2013-03-19 21:39:44) >> On Wed, 2013-03-20 at 11:31 +0800, Mike Turquette wrote: >> > Quoting Bill Huang (2013-03-19 19:55:49) >> > > On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote: >> > > > Quoting Bill Huang (2013-03-19 06:28:32) >> > > > > Add notifier calls in clk_prepare and clk_unprepare so drivers which >> > > > > are >> > > > > interested in knowing that clk_prepare/unprepare call can act >> > > > > accordingly. >> > > > > >> > > > > The existing "clk_set_rate" notifier is not enough for normal DVFS >> > > > > inplementation since clock might be enabled/disabled at runtime. >> > > > > Adding >> > > > > these notifiers is useful on DVFS core which take clk_prepare as a >> > > > > hint >> > > > > on that the notified clock might be enabled later so it can raise >> > > > > voltage >> > > > > to a safe level before enabling the clock, and take clk_unprepare as >> > > > > a >> > > > > hint that the clock has been disabled and is safe to lower the >> > > > > voltage. >> > > > > >> > > > > The added notifier events are: >> > > > > >> > > > > PRE_CLK_PREPARE >> > > > > POST_CLK_PREPARE >> > > > > ABORT_CLK_PREPARE >> > > > > PRE_CLK_UNPREPARE >> > > > > POST_CLK_UNPREPARE >> > > > > >> > > > > Signed-off-by: Bill Huang >> > > > >> > > > I'm still not sure about this approach. Based on feedback I got from >> > > > Linaro Connect I am not convinced that scaling voltage through clk >> > > > rate-change notifiers is the right way to go. As I understand it this >> > > > patch only exists for that single purpose, so if the voltage-notifier >> > > > idea gets dropped then I will not take this patch in. >> > > > >> > > Thanks Mike, actually we won't use your "clk: notifier handler for >> > > dynamic voltage scaling" patch instead we are trying to port our DVFS >> > > into Non-CPU DVFS framework "devfreq" which will need to hook those >> > > notifiers, without the clock notifiers been extended the framework is >> > > useless for us since we cannot do polling due to the fact that polling >> > > is not in real time. If it ended up extending the notifiers cannot >> > > happen then the only choice for us I think would be giving up "devfreq" >> > > and implement them in Tegra's "clk_hw". >> > >> > I'm familiar with the devfreq framework. Can you explain further how >> > you plan to use devfreq with the clock notifiers? What does the call >> > graph look like? >> > >> The call graph will look like this, when any DVFS interested clock rate >> changes (including enable and disable) happen -> Tegra devfreq clock >> notifier is called -> call into update_devfreq if needed -> in >> update_devfreq it will call into .get_target_freq in Tegra >> "devfreq_governor" -> and then call into .target of tegra >> devfreq_dev_profile to set voltage and done. More details are as below. >> >> We'll create devfreq driver for Tegra VDD_CORE rail, and the safe >> voltage level of the rail is determined by tens of clocks (2d, 3d, >> mpe,...), all the frequency ladders of those clocks are defined in DT >> also the operating points for VDD_CORE is declared in DT where its >> frequency will be more of a virtual clock or index. >> >> operating-points = < >> /* virtual-kHz uV */ >> 0 95 >> 1 100 >> 2 105 >> 3 110 >> 4 115 >> 5 120 >> 6 125 >> 7 130 >> 8 135 >> >> Register a Tegra governor where the callback .get_target_freq is the >> function to determine the overall frequency it can go to, and >> the .target callback in "devfreq_dev_profile" will be the function >> really do the voltage scaling. >> >> Tegra devfreq driver will register clock notifiers on all its interested >> clock and hence when any of those clock rate changes, disabled, enabled, >> we'll specifically call update_devfreq in the notifier. > > Thank you for the explanation. Do you plan to use actual devfreq > governors (like simple-ondemand, or something custom) for changing OPPs, > or do you just plan to use the clock framework as a trigger for DVFS? > > Regards, > Mike At a recent discussion regarding a previous version of this patch "[RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare", we also discussed whether to use clk notifiers or to use a clk hw to implement DVFS. Stephen Warren an myself, kind of pointed out that there could be benefits of not using notifers. I would just like to add that to this discussion as well. The idea in principle, could be as an option to Bill's idea, using devfreq with notifiers, to implement a clk hw which possibly makes use of the opp libary and do implements the DVFS functionallity that is needed for each SoC. Kind regards Ulf Hansson > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > htt
Re: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare
On Wed, 2013-03-20 at 22:47 +0800, Mike Turquette wrote: > Quoting Bill Huang (2013-03-19 21:39:44) > > On Wed, 2013-03-20 at 11:31 +0800, Mike Turquette wrote: > > > Quoting Bill Huang (2013-03-19 19:55:49) > > > > On Wed, 2013-03-20 at 01:01 +0800, Mike Turquette wrote: > > > > > I'm still not sure about this approach. Based on feedback I got from > > > > > Linaro Connect I am not convinced that scaling voltage through clk > > > > > rate-change notifiers is the right way to go. As I understand it this > > > > > patch only exists for that single purpose, so if the voltage-notifier > > > > > idea gets dropped then I will not take this patch in. > > > > > > > > > Thanks Mike, actually we won't use your "clk: notifier handler for > > > > dynamic voltage scaling" patch instead we are trying to port our DVFS > > > > into Non-CPU DVFS framework "devfreq" which will need to hook those > > > > notifiers, without the clock notifiers been extended the framework is > > > > useless for us since we cannot do polling due to the fact that polling > > > > is not in real time. If it ended up extending the notifiers cannot > > > > happen then the only choice for us I think would be giving up "devfreq" > > > > and implement them in Tegra's "clk_hw". > > > > > > I'm familiar with the devfreq framework. Can you explain further how > > > you plan to use devfreq with the clock notifiers? What does the call > > > graph look like? > > > > > The call graph will look like this, when any DVFS interested clock rate > > changes (including enable and disable) happen -> Tegra devfreq clock > > notifier is called -> call into update_devfreq if needed -> in > > update_devfreq it will call into .get_target_freq in Tegra > > "devfreq_governor" -> and then call into .target of tegra > > devfreq_dev_profile to set voltage and done. More details are as below. > > > > We'll create devfreq driver for Tegra VDD_CORE rail, and the safe > > voltage level of the rail is determined by tens of clocks (2d, 3d, > > mpe,...), all the frequency ladders of those clocks are defined in DT > > also the operating points for VDD_CORE is declared in DT where its > > frequency will be more of a virtual clock or index. > > > > operating-points = < > > /* virtual-kHz uV */ > > 0 95 > > 1 100 > > 2 105 > > 3 110 > > 4 115 > > 5 120 > > 6 125 > > 7 130 > > 8 135 > > > > Register a Tegra governor where the callback .get_target_freq is the > > function to determine the overall frequency it can go to, and > > the .target callback in "devfreq_dev_profile" will be the function > > really do the voltage scaling. > > > > Tegra devfreq driver will register clock notifiers on all its interested > > clock and hence when any of those clock rate changes, disabled, enabled, > > we'll specifically call update_devfreq in the notifier. > > Thank you for the explanation. Do you plan to use actual devfreq > governors (like simple-ondemand, or something custom) for changing OPPs, > or do you just plan to use the clock framework as a trigger for DVFS? > I think the existing governors are all polling basis that do not work for us, we have only single voltage rails and have tens of clocks which are used by different device drivers, the voltage has to be boost before the frequency is increasing, and it can only be lower after all the interested clocks rate are allowing it to or we might crash. Clock notifier seem to be the only choice to build association with all those interested device driver (in real time) who might make changes on clock rate either by using runtime PM or the similar mechanism. We do use OPP in our devfreq driver, we just need to do some extra work on checking all the interested clocks for making sure we will be choosing the correct operating point for the power rail. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Samsung topic for 13.03
> Looks like the ll-20130320.0 kernel failed to boot on Arndale: > http://validation.linaro.org/lava-server/scheduler/job/49985/log_file > > The build log is here: > https://ci.linaro.org/jenkins/job/linux-linaro-tracking_arndale/62/consoleFull > > > The kernel config has been made by the following command: > 'ARCH=arm scripts/kconfig/merge_config.sh > linaro/configs/linaro-base.conf linaro/configs/ubuntu-minimal.conf > linaro/configs/arndale.conf linaro/configs/kvm-host.conf' > > Tushar, > Have you tried this configuration? > > Thanks, > Andrey I have been observing this system hang when we enable LPAE on 3.9 based llct, though the issue is not present with vanilla 3.9-rc kernel. Would update later after I debug further. Riku, How much essential is it to enable LPAE support for KVM? -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
