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
Hi Guys,
Can you please have a look at the below patchset? Your review comments
are very necessary and valuable.Thanks in advance.
> This patchset uses the per-entity-load-tracking patchset which will soon be
> available in the kernel.It is based on the tip/master tree and the first 8
> latest patches of sched:per-entity-load-tracking alone have been imported to
> the tree to avoid the complexities of task groups and to hold back the
> optimizations of this patch for now.
>
> This patchset is an attempt to begin the integration of Per-entity-load-
> metric for the cfs_rq,henceforth referred to as PJT's metric,with the load
> balancer in a step wise fashion,and progress based on the consequences.
>
> The following issues have been considered towards this:
> [NOTE:an x% task referred to in the logs and below is calculated over a
> duty cycle of 10ms.]
>
> 1.Consider a scenario,where there are two 10% tasks running on a cpu.The
> present code will consider the load on this queue to be 2048,while
> using PJT's metric the load is calculated to be <1000,rarely exceeding this
> limit.Although the tasks are not contributing much to the cpu load,they are
> decided to be moved by the scheduler.
>
> But one could argue that 'not moving one of these tasks could throttle
> them.If there was an idle cpu,perhaps we could have moved them'.While the
> power save mode would have been fine with not moving the task,the
> performance mode would prefer not to throttle the tasks.We could strive
> to strike a balance by making this decision tunable with certain parameters.
> This patchset includes such tunables.This issue is addressed in Patch[1/2].
>
> 2.We need to be able to do this cautiously,as the scheduler code is too
> complex.This patchset is an attempt to begin the integration of PJT's
> metric with the load balancer in a step wise fashion,and progress based on
> the consequences.
> I dont intend to vary the parameters used by the load balancer.Some
> parameters are however included anew to make decisions about including a
> sched group as a candidate for load balancing.
>
> This patchset therefore has two primary aims.
> Patch[1/2]: This patch aims at detecting short running tasks and
> prevent their movement.In update_sg_lb_stats,dismiss a sched group
> as a candidate for load balancing,if load calculated by PJT's metric
> says that the average load on the sched_group <= 1024+(.15*1024).
> This is a tunable,which can be varied after sufficient experiments.
>
> Patch[2/2]:In the current scheduler greater load would be analogous
> to more number of tasks.Therefore when the busiest group is picked
> from the sched domain in update_sd_lb_stats,only the loads of the
> groups are compared between them.If we were to use PJT's metric,a
> higher load does not necessarily mean more number of tasks.This
> patch addresses this issue.
>
> 3.The next step towards integration should be in using the PJT's metric for
> comparison between the loads of the busy sched group and the sched
> group which has to pull the tasks,which happens in find_busiest_group.
> ---
>
> Preeti U Murthy (2):
> sched:Prevent movement of short running tasks during load balancing
> sched:Pick the apt busy sched group during load balancing
>
>
> kernel/sched/fair.c | 38 +++++++++++++++++++++++++++++++++++---
> 1 file changed, 35 insertions(+), 3 deletions(-)
>
> --
The links to PATCH[1/2] https://lkml.org/lkml/2012/10/12/13
PATCH[2/2] https://lkml.org/lkml/2012/10/12/11
Regards
Preeti U Murthy
The following patchset does some cleanup and prepares the place for the
multiple driver support.
We want to add an entry per cpu for the driver when the configuration defines
the support for multiple cpuidle drivers. This patchset creates a single
entry function for adding a cpuidle device to the sysfs where we will add
the driver entry in the next patchset. In order to do that, the kobj handling
is grouped in the sysfs.c file and the function prototype is changed.
In any case, the patchset cleans up and groups the code but does not change
the behavior, this is why it is submitted as a separate patchset rather
than join it with the multiple drivers support.
Daniel Lezcano (4):
cpuidle - sysfs : change function parameter
cpuidle - sysfs : move kobj initialization in the syfs file
cpuidle - sysfs : change function name
cpuidle - sysfs : move definition in the sysfs file
drivers/cpuidle/cpuidle.c | 19 ++++++----------
drivers/cpuidle/cpuidle.h | 10 +++-----
drivers/cpuidle/sysfs.c | 52 ++++++++++++++++++++++++++++++++-------------
include/linux/cpuidle.h | 7 ------
4 files changed, 48 insertions(+), 40 deletions(-)
--
1.7.5.4
> On Monday 08 of October 2012 10:48:24 MyungJoo Ham wrote:
> > > On 8 October 2012 03:31, Rafael J. Wysocki <rjw(a)sisk.pl> wrote:
> > > > On Thursday 04 of October 2012 14:58:33 Rajagopal Venkat wrote:
> > > >> Add devfreq suspend/resume apis for devfreq users. This patch
> > > >> supports suspend and resume of devfreq load monitoring, required
> > > >> for devices which can idle.
> > > >>
> > > >> Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org>
> > > >> Acked-by: MyungJoo Ham <myungjoo.ham(a)samsung.com>
> > > >
> > > > Well, I wonder if this may be tied in to the runtime PM framework, so that,
> > > > for example, pm_runtime_suspend() will automatically suspend devfreq on
> > > > success (and the runtime resume of the device will resume devfreq)?
> > >
> > > That's a good idea. If you agree, we can handle this as separate patch on
> > > top this patchset.
>
> Sure.
>
> > I guess implementing the idea may be not so obvious; thus, seperating
> > the patchset would be appropriate.
> >
> > When we implement the idea, we may need to implement at the
> > pm_runtime core. Because devfreq->dev is a child of the target dev, not
> > a parent, runtime-pm event of the target dev does not automatically
> > invoke a cascaded action on the devfreq->dev.
>
> I'm not exactly sure what you mean, care to explain?
When a device "p" creates devfreq, devfreq->dev->parent = p.
And, devfreq's functions need to react to the "p"'s runtime-pm events.
However, when "p"'s runtime-pm-suspend is being invoked,
devfreq->dev's runtime-pm-suspend won't be automatically invoked.
Thus, we will need a mechanism that invokes devfreq->dev's runtime-pm
callbacks when p's runtime-pm is invoked. (at the runtime-pm core)
Or
A mechanism that one can notify others (including its children) when
the one's runtime-pm is invoked. (probably at the runtime-pm core, too)
Without such support, it appears that the current implementation
(calling runtime-pm suspend/resume equivalent devfreq functions
manually at device drivers) seems to be inevitable.
Anyway, if devfreq->dev is a parent of "p", runtime-pm core will
do the required task automatically; however, it isn't and I don't
think it'd be appropriate.
>
> > Maybe either
> > 1) capability to allow a child to monitor the power state of a parent
> > (I remember Inki Dae once suggested to add notifiers at runtime-pm, but
> > it seems to be not merged)
> > or
> > 2) letting runtime-pm be aware of devfreq
> > (doesn't feel alright with this??)
> > is required?
>
> I'm not a big fan of notifiers, so I'd prefer to avoid using them, if
> possible.
>
> Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
>
Cheers,
MyungJoo
Arrays for governer and driver name are of size CPUFREQ_NAME_LEN or 16.
i.e. 15 bytes for name and 1 for trailing '\0'.
When cpufreq driver print these names (for sysfs), it includes '\n' or ' ' in
the fmt string and still passes length as CPUFREQ_NAME_LEN. If the driver or
governor names are using all 15 fields allocated to them, then the trailing '\n'
or ' ' will never be printed. And so commands like:
root@linaro-developer# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
will print something like:
cpufreq_foodrvroot@linaro-developer#
Fix this by increasing print length by one character.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/cpufreq.c | 6 +++---
include/linux/cpufreq.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 021973b..db6e337 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -445,7 +445,7 @@ static ssize_t show_scaling_governor(struct cpufreq_policy *policy, char *buf)
else if (policy->policy == CPUFREQ_POLICY_PERFORMANCE)
return sprintf(buf, "performance\n");
else if (policy->governor)
- return scnprintf(buf, CPUFREQ_NAME_LEN, "%s\n",
+ return scnprintf(buf, CPUFREQ_NAME_PLEN, "%s\n",
policy->governor->name);
return -EINVAL;
}
@@ -491,7 +491,7 @@ static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
*/
static ssize_t show_scaling_driver(struct cpufreq_policy *policy, char *buf)
{
- return scnprintf(buf, CPUFREQ_NAME_LEN, "%s\n", cpufreq_driver->name);
+ return scnprintf(buf, CPUFREQ_NAME_PLEN, "%s\n", cpufreq_driver->name);
}
/**
@@ -512,7 +512,7 @@ static ssize_t show_scaling_available_governors(struct cpufreq_policy *policy,
if (i >= (ssize_t) ((PAGE_SIZE / sizeof(char))
- (CPUFREQ_NAME_LEN + 2)))
goto out;
- i += scnprintf(&buf[i], CPUFREQ_NAME_LEN, "%s ", t->name);
+ i += scnprintf(&buf[i], CPUFREQ_NAME_PLEN, "%s ", t->name);
}
out:
i += sprintf(&buf[i], "\n");
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index b60f6ba..fc4b785 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -22,6 +22,8 @@
#include <asm/div64.h>
#define CPUFREQ_NAME_LEN 16
+/* Print length for names. Extra 1 space for accomodating '\n' in prints */
+#define CPUFREQ_NAME_PLEN (CPUFREQ_NAME_LEN + 1)
/*********************************************************************
--
1.7.12.rc2.18.g61b472e
Hello Ming,
could you please give some pointers to observe an overall status of
oprofile support on ARM A9 cores? IIUC, now it doesn't work
without oprofile.timer=1 kernel option, at least for Linus' tree;
searching gives a lot of discussion/patches fragments and similar
stuff, but I was unable to find a complete patch/git tree/whatever
else to try.
Thanks in advance,
Dmitry
