* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Michael Neuling @ 2010-02-19 11:01 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <1266573672.1806.70.camel@laptop>
In message <1266573672.1806.70.camel@laptop> you wrote:
> On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > > include/linux/sched.h | 2 +-
> > > kernel/sched_fair.c | 61 +++++++++++++++++++++++++++++++++++++++++++
++--
> > -
> > > 2 files changed, 58 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index 0eef87b..42fa5c6 100644
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -849,7 +849,7 @@ enum cpu_idle_type {
> > > #define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
> > > #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
> > resources */
> > > #define SD_SERIALIZE 0x0400 /* Only a single load balancing
instanc
> > e */
> > > -
> > > +#define SD_ASYM_PACKING 0x0800
> >
> > Would we eventually add this to SD_SIBLING_INIT in a arch specific hook,
> > or is this ok to add it generically?
>
> I'd think we'd want to keep that limited to architectures that actually
> need it.
OK
> >
> > > +static int update_sd_pick_busiest(struct sched_domain *sd,
> > > + struct sd_lb_stats *sds,
> > > + struct sched_group *sg,
> > > + struct sg_lb_stats *sgs)
> > > +{
> > > + if (sgs->sum_nr_running > sgs->group_capacity)
> > > + return 1;
> > > +
> > > + if (sgs->group_imb)
> > > + return 1;
> > > +
> > > + if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
> > > + if (!sds->busiest)
> > > + return 1;
> > > +
> > > + if (group_first_cpu(sds->busiest) < group_first_cpu(group))
> >
> > "group" => "sg" here? (I get a compile error otherwise)
>
> Oh, quite ;-)
>
> > > +static int check_asym_packing(struct sched_domain *sd,
> > > + struct sd_lb_stats *sds,
> > > + int cpu, unsigned long *imbalance)
> > > +{
> > > + int i, cpu, busiest_cpu;
> >
> > Redefining cpu here. Looks like the cpu parameter is not really needed?
>
> Seems that way indeed, I went back and forth a few times on the actual
> implementation of this function (which started out live as a copy of
> check_power_save_busiest_group), its amazing there were only these two
> compile glitches ;-)
:-)
Below are the cleanups + the arch specific bits. It doesn't change your
logic at all. Obviously the PPC arch bits would need to be split into a
separate patch.
Compiles and boots against linux-next.
Mikey
---
arch/powerpc/include/asm/cputable.h | 3 +
arch/powerpc/kernel/process.c | 7 +++
include/linux/sched.h | 4 +-
include/linux/topology.h | 1
kernel/sched_fair.c | 64 ++++++++++++++++++++++++++++++++++--
5 files changed, 74 insertions(+), 5 deletions(-)
Index: linux-next/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-next.orig/arch/powerpc/include/asm/cputable.h
+++ linux-next/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
+#define CPU_FTR_ASYM_SMT4 LONG_ASM_CONST(0x0100000000000000)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT4)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Index: linux-next/arch/powerpc/kernel/process.c
===================================================================
--- linux-next.orig/arch/powerpc/kernel/process.c
+++ linux-next/arch/powerpc/kernel/process.c
@@ -1265,3 +1265,10 @@ unsigned long randomize_et_dyn(unsigned
return ret;
}
+
+int arch_sd_asym_packing(void)
+{
+ if (cpu_has_feature(CPU_FTR_ASYM_SMT4))
+ return SD_ASYM_PACKING;
+ return 0;
+}
Index: linux-next/include/linux/sched.h
===================================================================
--- linux-next.orig/include/linux/sched.h
+++ linux-next/include/linux/sched.h
@@ -849,7 +849,7 @@ enum cpu_idle_type {
#define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing instance */
-
+#define SD_ASYM_PACKING 0x0800 /* Asymetric SMT packing */
#define SD_PREFER_SIBLING 0x1000 /* Prefer to place tasks in a sibling domain */
enum powersavings_balance_level {
@@ -881,6 +881,8 @@ static inline int sd_balance_for_package
return SD_PREFER_SIBLING;
}
+extern int arch_sd_asym_packing(void);
+
/*
* Optimise SD flags for power savings:
* SD_BALANCE_NEWIDLE helps agressive task consolidation and power savings.
Index: linux-next/include/linux/topology.h
===================================================================
--- linux-next.orig/include/linux/topology.h
+++ linux-next/include/linux/topology.h
@@ -102,6 +102,7 @@ int arch_update_cpu_topology(void);
| 1*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE \
| 0*SD_PREFER_SIBLING \
+ | arch_sd_asym_packing() \
, \
.last_balance = jiffies, \
.balance_interval = 1, \
Index: linux-next/kernel/sched_fair.c
===================================================================
--- linux-next.orig/kernel/sched_fair.c
+++ linux-next/kernel/sched_fair.c
@@ -2086,6 +2086,7 @@ struct sd_lb_stats {
struct sched_group *this; /* Local group in this sd */
unsigned long total_load; /* Total load of all groups in sd */
unsigned long total_pwr; /* Total power of all groups in sd */
+ unsigned long total_nr_running;
unsigned long avg_load; /* Average load across all groups in sd */
/** Statistics of this group */
@@ -2493,6 +2494,28 @@ static inline void update_sg_lb_stats(st
DIV_ROUND_CLOSEST(group->cpu_power, SCHED_LOAD_SCALE);
}
+static int update_sd_pick_busiest(struct sched_domain *sd,
+ struct sd_lb_stats *sds,
+ struct sched_group *sg,
+ struct sg_lb_stats *sgs)
+{
+ if (sgs->sum_nr_running > sgs->group_capacity)
+ return 1;
+
+ if (sgs->group_imb)
+ return 1;
+
+ if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
+ if (!sds->busiest)
+ return 1;
+
+ if (group_first_cpu(sds->busiest) < group_first_cpu(sg))
+ return 1;
+ }
+
+ return 0;
+}
+
/**
* update_sd_lb_stats - Update sched_group's statistics for load balancing.
* @sd: sched_domain whose statistics are to be updated.
@@ -2533,6 +2556,7 @@ static inline void update_sd_lb_stats(st
sds->total_load += sgs.group_load;
sds->total_pwr += group->cpu_power;
+ sds->total_nr_running += sgs.sum_nr_running;
/*
* In case the child domain prefers tasks go to siblings
@@ -2547,9 +2571,8 @@ static inline void update_sd_lb_stats(st
sds->this = group;
sds->this_nr_running = sgs.sum_nr_running;
sds->this_load_per_task = sgs.sum_weighted_load;
- } else if (sgs.avg_load > sds->max_load &&
- (sgs.sum_nr_running > sgs.group_capacity ||
- sgs.group_imb)) {
+ } else if (sgs.avg_load >= sds->max_load &&
+ update_sd_pick_busiest(sd, sds, group, &sgs)) {
sds->max_load = sgs.avg_load;
sds->busiest = group;
sds->busiest_nr_running = sgs.sum_nr_running;
@@ -2562,6 +2585,38 @@ static inline void update_sd_lb_stats(st
} while (group != sd->groups);
}
+int __weak sd_asym_packing_arch(void)
+{
+ return 0;
+}
+
+static int check_asym_packing(struct sched_domain *sd,
+ struct sd_lb_stats *sds,
+ unsigned long *imbalance)
+{
+ int i, cpu, busiest_cpu;
+
+ if (!(sd->flags & SD_ASYM_PACKING))
+ return 0;
+
+ if (!sds->busiest)
+ return 0;
+
+ i = 0;
+ busiest_cpu = group_first_cpu(sds->busiest);
+ for_each_cpu(cpu, sched_domain_span(sd)) {
+ i++;
+ if (cpu == busiest_cpu)
+ break;
+ }
+
+ if (sds->total_nr_running > i)
+ return 0;
+
+ *imbalance = sds->max_load;
+ return 1;
+}
+
/**
* fix_small_imbalance - Calculate the minor imbalance that exists
* amongst the groups of a sched_domain, during
@@ -2761,6 +2816,9 @@ find_busiest_group(struct sched_domain *
return sds.busiest;
out_balanced:
+ if (check_asym_packing(sd, &sds, imbalance))
+ return sds.busiest;
+
/*
* There is no obvious imbalance. But check if we can do some balancing
* to save power.
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Peter Zijlstra @ 2010-02-19 10:01 UTC (permalink / raw)
To: Michael Neuling; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <14639.1266559532@neuling.org>
On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > include/linux/sched.h | 2 +-
> > kernel/sched_fair.c | 61 +++++++++++++++++++++++++++++++++++++++++++++--
> -
> > 2 files changed, 58 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 0eef87b..42fa5c6 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -849,7 +849,7 @@ enum cpu_idle_type {
> > #define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
> > #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
> resources */
> > #define SD_SERIALIZE 0x0400 /* Only a single load balancing instanc
> e */
> > -
> > +#define SD_ASYM_PACKING 0x0800
>
> Would we eventually add this to SD_SIBLING_INIT in a arch specific hook,
> or is this ok to add it generically?
I'd think we'd want to keep that limited to architectures that actually
need it.
>
> > +static int update_sd_pick_busiest(struct sched_domain *sd,
> > + struct sd_lb_stats *sds,
> > + struct sched_group *sg,
> > + struct sg_lb_stats *sgs)
> > +{
> > + if (sgs->sum_nr_running > sgs->group_capacity)
> > + return 1;
> > +
> > + if (sgs->group_imb)
> > + return 1;
> > +
> > + if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
> > + if (!sds->busiest)
> > + return 1;
> > +
> > + if (group_first_cpu(sds->busiest) < group_first_cpu(group))
>
> "group" => "sg" here? (I get a compile error otherwise)
Oh, quite ;-)
> > +static int check_asym_packing(struct sched_domain *sd,
> > + struct sd_lb_stats *sds,
> > + int cpu, unsigned long *imbalance)
> > +{
> > + int i, cpu, busiest_cpu;
>
> Redefining cpu here. Looks like the cpu parameter is not really needed?
Seems that way indeed, I went back and forth a few times on the actual
implementation of this function (which started out live as a copy of
check_power_save_busiest_group), its amazing there were only these two
compile glitches ;-)
> > +
> > + if (!(sd->flags & SD_ASYM_PACKING))
> > + return 0;
> > +
> > + if (!sds->busiest)
> > + return 0;
> > +
> > + i = 0;
> > + busiest_cpu = group_first_cpu(sds->busiest);
> > + for_each_cpu(cpu, sched_domain_span(sd)) {
> > + i++;
> > + if (cpu == busiest_cpu)
> > + break;
> > + }
> > +
> > + if (sds->total_nr_running > i)
> > + return 0;
> > +
> > + *imbalance = sds->max_load;
> > + return 1;
> > +}
^ permalink raw reply
* Re: State of PREEMPT_RT in PPC arch
From: Wolfram Sang @ 2010-02-19 8:54 UTC (permalink / raw)
To: Ryan; +Cc: ppcdev
In-Reply-To: <5bbdacc81002182134l64c46bf1mc2a4b4fc268e6eee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]
On Thu, Feb 18, 2010 at 09:34:28PM -0800, Ryan wrote:
> On Thu, Feb 18, 2010 at 5:15 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> >
> > > I'm soliciting comments from the community. Thanks in advance for
> > > sharing your thoughts.
> >
> > Mainline your driver and you are free from such problems :)
>
> Shouldn't it be the opposite way? That is, get drivers working first
> then mainline them? I even don't have a working driver with RT patch.
If you have problems getting your driver to mainline, the lists are there to
help. Of course, this implies working with a recent kernel (which also answers
your initial question a bit). Most people don't want to supprt old kernels like
2.6.2x in their freetime. You can get commercial support for such tasks (be it
my employer or other consultants on this list).
> and discussions about them, kinda dedicated to active developers. Is
> there a place that users or not-so-active developers can post
> technical questions and get some relatively quick answers or comments?
The list was apropriate. As all people are busy by default, getting no response
is not that exceptional. If you need a fast response, you should consider
commercial support.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Michael Neuling @ 2010-02-19 6:05 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <1266499023.26719.597.camel@laptop>
> On Thu, 2010-02-18 at 09:20 +1100, Michael Neuling wrote:
> > > Suppose for a moment we have 2 threads (hot-unplugged thread 1 and 3, we
> > > can construct an equivalent but more complex example for 4 threads), and
> > > we have 4 tasks, 3 SCHED_OTHER of equal nice level and 1 SCHED_FIFO, the
> > > SCHED_FIFO task will consume exactly 50% walltime of whatever cpu it
> > > ends up on.
> > >
> > > In that situation, provided that each cpu's cpu_power is of equal
> > > measure, scale_rt_power() ensures that we run 2 SCHED_OTHER tasks on the
> > > cpu that doesn't run the RT task, and 1 SCHED_OTHER task next to the RT
> > > task, so that each task consumes 50%, which is all fair and proper.
> > >
> > > However, if you do the above, thread 0 will have +75% = 1.75 and thread
> > > 2 will have -75% = 0.25, then if the RT task will land on thread 0,
> > > we'll be having: 0.875 vs 0.25, or on thread 3, 1.75 vs 0.125. In either
> > > case thread 0 will receive too many (if not all) SCHED_OTHER tasks.
> > >
> > > That is, unless these threads 2 and 3 really are _that_ weak, at which
> > > point one wonders why IBM bothered with the silicon ;-)
> >
> > Peter,
> >
> > 2 & 3 aren't weaker than 0 & 1 but....
> >
> > The core has dynamic SMT mode switching which is controlled by the
> > hypervisor (IBM's PHYP). There are 3 SMT modes:
> > SMT1 uses thread 0
> > SMT2 uses threads 0 & 1
> > SMT4 uses threads 0, 1, 2 & 3
> > When in any particular SMT mode, all threads have the same performance
> > as each other (ie. at any moment in time, all threads perform the same).
> >
> > The SMT mode switching works such that when linux has threads 2 & 3 idle
> > and 0 & 1 active, it will cede (H_CEDE hypercall) threads 2 and 3 in the
> > idle loop and the hypervisor will automatically switch to SMT2 for that
> > core (independent of other cores). The opposite is not true, so if
> > threads 0 & 1 are idle and 2 & 3 are active, we will stay in SMT4 mode.
> >
> > Similarly if thread 0 is active and threads 1, 2 & 3 are idle, we'll go
> > into SMT1 mode.
> >
> > If we can get the core into a lower SMT mode (SMT1 is best), the threads
> > will perform better (since they share less core resources). Hence when
> > we have idle threads, we want them to be the higher ones.
>
> Just out of curiosity, is this a hardware constraint or a hypervisor
> constraint?
>
> > So to answer your question, threads 2 and 3 aren't weaker than the other
> > threads when in SMT4 mode. It's that if we idle threads 2 & 3, threads
> > 0 & 1 will speed up since we'll move to SMT2 mode.
> >
> > I'm pretty vague on linux scheduler details, so I'm a bit at sea as to
> > how to solve this. Can you suggest any mechanisms we currently have in
> > the kernel to reflect these properties, or do you think we need to
> > develop something new? If so, any pointers as to where we should look?
>
> Well there currently isn't one, and I've been telling people to create a
> new SD_flag to reflect this and influence the f_b_g() behaviour.
>
> Something like the below perhaps, totally untested and without comments
> so that you'll have to reverse engineer and validate my thinking.
>
> There's one fundamental assumption, and one weakness in the
> implementation.
Thanks for the help.
I'm still trying to get up to speed with how this works but while trying
to cleanup and compile your patch, I had some simple questions below...
>
> ---
>
> include/linux/sched.h | 2 +-
> kernel/sched_fair.c | 61 +++++++++++++++++++++++++++++++++++++++++++++--
-
> 2 files changed, 58 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 0eef87b..42fa5c6 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -849,7 +849,7 @@ enum cpu_idle_type {
> #define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
> #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
> #define SD_SERIALIZE 0x0400 /* Only a single load balancing instanc
e */
> -
> +#define SD_ASYM_PACKING 0x0800
Would we eventually add this to SD_SIBLING_INIT in a arch specific hook,
or is this ok to add it generically?
> #define SD_PREFER_SIBLING 0x1000 /* Prefer to place tasks in a sibling d
omain */
>
> enum powersavings_balance_level {
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index ff7692c..7e42bfe 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -2086,6 +2086,7 @@ struct sd_lb_stats {
> struct sched_group *this; /* Local group in this sd */
> unsigned long total_load; /* Total load of all groups in sd */
> unsigned long total_pwr; /* Total power of all groups in sd */
> + unsigned long total_nr_running;
> unsigned long avg_load; /* Average load across all groups in sd */
>
> /** Statistics of this group */
> @@ -2414,10 +2415,10 @@ static inline void update_sg_lb_stats(struct sched_do
main *sd,
> int *balance, struct sg_lb_stats *sgs)
> {
> unsigned long load, max_cpu_load, min_cpu_load;
> - int i;
> unsigned int balance_cpu = -1, first_idle_cpu = 0;
> unsigned long sum_avg_load_per_task;
> unsigned long avg_load_per_task;
> + int i;
>
> if (local_group)
> balance_cpu = group_first_cpu(group);
> @@ -2493,6 +2494,28 @@ static inline void update_sg_lb_stats(struct sched_dom
ain *sd,
> DIV_ROUND_CLOSEST(group->cpu_power, SCHED_LOAD_SCALE);
> }
>
> +static int update_sd_pick_busiest(struct sched_domain *sd,
> + struct sd_lb_stats *sds,
> + struct sched_group *sg,
> + struct sg_lb_stats *sgs)
> +{
> + if (sgs->sum_nr_running > sgs->group_capacity)
> + return 1;
> +
> + if (sgs->group_imb)
> + return 1;
> +
> + if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
> + if (!sds->busiest)
> + return 1;
> +
> + if (group_first_cpu(sds->busiest) < group_first_cpu(group))
"group" => "sg" here? (I get a compile error otherwise)
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> /**
> * update_sd_lb_stats - Update sched_group's statistics for load balancing.
> * @sd: sched_domain whose statistics are to be updated.
> @@ -2533,6 +2556,7 @@ static inline void update_sd_lb_stats(struct sched_domain *sd, int this_cpu,
>
> sds->total_load += sgs.group_load;
> sds->total_pwr += group->cpu_power;
> + sds->total_nr_running += sgs.sum_nr_running;
>
> /*
> * In case the child domain prefers tasks go to siblings
> @@ -2547,9 +2571,8 @@ static inline void update_sd_lb_stats(struct sched_domain *sd, int this_cpu,
> sds->this = group;
> sds->this_nr_running = sgs.sum_nr_running;
> sds->this_load_per_task = sgs.sum_weighted_load;
> - } else if (sgs.avg_load > sds->max_load &&
> - (sgs.sum_nr_running > sgs.group_capacity ||
> - sgs.group_imb)) {
> + } else if (sgs.avg_load >= sds->max_load &&
> + update_sd_pick_busiest(sd, sds, group, &sgs)) {
> sds->max_load = sgs.avg_load;
> sds->busiest = group;
> sds->busiest_nr_running = sgs.sum_nr_running;
> @@ -2562,6 +2585,33 @@ static inline void update_sd_lb_stats(struct sched_dom
ain *sd, int this_cpu,
> } while (group != sd->groups);
> }
>
> +static int check_asym_packing(struct sched_domain *sd,
> + struct sd_lb_stats *sds,
> + int cpu, unsigned long *imbalance)
> +{
> + int i, cpu, busiest_cpu;
Redefining cpu here. Looks like the cpu parameter is not really needed?
> +
> + if (!(sd->flags & SD_ASYM_PACKING))
> + return 0;
> +
> + if (!sds->busiest)
> + return 0;
> +
> + i = 0;
> + busiest_cpu = group_first_cpu(sds->busiest);
> + for_each_cpu(cpu, sched_domain_span(sd)) {
> + i++;
> + if (cpu == busiest_cpu)
> + break;
> + }
> +
> + if (sds->total_nr_running > i)
> + return 0;
> +
> + *imbalance = sds->max_load;
> + return 1;
> +}
> +
> /**
> * fix_small_imbalance - Calculate the minor imbalance that exists
> * amongst the groups of a sched_domain, during
> @@ -2761,6 +2811,9 @@ find_busiest_group(struct sched_domain *sd, int this_cp
u,
> return sds.busiest;
>
> out_balanced:
> + if (check_asym_packing(sd, &sds, this_cpu, imbalance))
> + return sds.busiest;
> +
> /*
> * There is no obvious imbalance. But check if we can do some balancing
> * to save power.
>
>
^ permalink raw reply
* Re: State of PREEMPT_RT in PPC arch
From: Ryan @ 2010-02-19 5:34 UTC (permalink / raw)
To: Wolfram Sang; +Cc: ppcdev
In-Reply-To: <20100218131541.GB18514@pengutronix.de>
On Thu, Feb 18, 2010 at 5:15 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
> > I'm soliciting comments from the community. Thanks in advance for
> > sharing your thoughts.
>
> Mainline your driver and you are free from such problems :)
Shouldn't it be the opposite way? That is, get drivers working first
then mainline them? I even don't have a working driver with RT patch.
Thanks for the response though. At least it shows that such emails are
not completely ignored.
I feel the linuxppc-dev mailing list is full of development patches
and discussions about them, kinda dedicated to active developers. Is
there a place that users or not-so-active developers can post
technical questions and get some relatively quick answers or comments?
I think there used to be such a mailing list but I couldn't remember
it.
-Ryan.
^ permalink raw reply
* [-next Feb 18] PowerPC boot failure (Unknowd ADD relocation :26)
From: Sachin Sant @ 2010-02-19 4:20 UTC (permalink / raw)
To: linux-next, Linux/PPC Development; +Cc: Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
Yesterday's next failed to boot on various powerpc boxes
with following error :
NET: Registered protocol family 15
registered taskstats version 1
Freeing unused kernel memory: 640k freed
doing fast boot
scsi_mod: Unknown ADD relocation: 26
WARNING: Error inserting scsi_mod (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/scsi_mod.ko): Invalid module format
scsi_tgt: Unknown symbol scsi_release_buffers
scsi_tgt: Unknown symbol scsi_host_put
scsi_tgt: Unknown symbol __scsi_put_command
scsi_tgt: Unknown symbol scsi_host_lookup
scsi_tgt: Unknown symbol __scsi_get_command
scsi_tgt: Unknown symbol scsi_init_io
scsi_tgt: Unknown symbol __scsi_alloc_queue
and many more such modules related errors.
I have attached the boot log here.
Next Feb 17th was OK. Haven't yet tried the git bisect.
Will try that out today.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: boot-log --]
[-- Type: text/plain, Size: 9659 bytes --]
Using 00825420 bytes for initrd buffer
Please wait, loading kernel...
Allocated 00f00000 bytes for kernel @ 00d00000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 00825420 @ 034d0000
OF stdout device is: /vdevice/vty@30000000
Preparing to boot Linux version 2.6.33-rc8-autotest-next-20100218 (root@llm62) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu Feb 18 17:49:40 IST 2010
Max number of cores passed to firmware: 0x0000000000000200
Calling ibm,client-architecture-support... done
command line: root=/dev/sda5 IDENT=1266496633
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000003d00000
alloc_top : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top : 0000000008000000
ram_top : 0000000008000000
instantiating rtas at 0x00000000074e0000... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000003d10000 -> 0x0000000003d115fa
Device tree struct 0x0000000003d20000 -> 0x0000000003d40000
Calling quiesce...
returning from prom_init
Using pSeries machine description
Using 1TB segments
Found initrd at 0xc0000000034d0000:0xc000000003cf5420
bootconsole [udbg0] enabled
Partition configured for 4 cpus.
CPU maps initialized for 2 threads per core
Starting Linux PPC64 #1 SMP Thu Feb 18 17:49:40 IST 2010
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0x100000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.33-rc8-autotest-next-20100218 (root@llm62) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu Feb 18 17:49:40 IST 2010
[boot]0012 Setup Arch
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal 0x00010000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
1: 0x00000000 -> 0x00010000
Could not find start_pfn for node 0
[boot]0015 Setup Done
PERCPU: Embedded 2 pages/cpu @c000000000f00000 s89768 r0 d41304 u262144
pcpu-alloc: s89768 r0 d41304 u262144 alloc=1*1048576
pcpu-alloc: [0] 0 1 2 3
Built 2 zonelists in Node order, mobility grouping on. Total pages: 65480
Policy zone: DMA
Kernel command line: root=/dev/sda5 IDENT=1266496633
PID hash table entries: 4096 (order: -1, 32768 bytes)
freeing bootmem node 1
Memory: 4142272k/4194304k available (9280k kernel code, 52032k reserved, 2624k data, 2287k bss, 640k init)
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is enabled.
NR_IRQS:512 nr_irqs:512
[boot]0020 XICS Init
[boot]0021 XICS Done
clocksource: timebase mult[7d0000] shift[22] registered
Console: colour dummy device 80x25
console [hvc0] enabled, bootconsole disabled
console [hvc0] enabled, bootconsole disabled
allocated 2621440 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Security Framework initialized
SELinux: Disabled at boot.
Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys blkio
Processor 1 found.
Processor 2 found.
Processor 3 found.
Brought up 4 CPUs
devtmpfs: initialized
NET: Registered protocol family 16
IBM eBus Device Driver
POWER6 performance monitor hardware support registered
PCI: Probing PCI hardware
bio: create slab <bio-0> at 0
vgaarb: loaded
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 2048 (order: 0, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
Freeing initrd memory: 8341k freed
IOMMU table initialized, virtual merging enabled
audit: initializing netlink socket (disabled)
type=2000 audit(1266496684.180:1): initialized
rcu-torture:--- Start of test: nreaders=8 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
msgmni has been set to 8104
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
Generic RTC Driver v1.07
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
mice: PS/2 mouse device common for all mice
EDAC MC: Ver: 2.1.0 Feb 18 2010
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 15
registered taskstats version 1
Freeing unused kernel memory: 640k freed
doing fast boot
scsi_mod: Unknown ADD relocation: 26
WARNING: Error inserting scsi_mod (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/scsi_mod.ko): Invalid module format
scsi_tgt: Unknown symbol scsi_release_buffers
scsi_tgt: Unknown symbol scsi_host_put
scsi_tgt: Unknown symbol __scsi_put_command
scsi_tgt: Unknown symbol scsi_host_lookup
scsi_tgt: Unknown symbol __scsi_get_command
scsi_tgt: Unknown symbol scsi_init_io
scsi_tgt: Unknown symbol __scsi_alloc_queue
WARNING: Error inserting scsi_tgt (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/scsi_tgt.ko): Unknown symbol in module, or unknown parameter (see dmesg)
scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_destroy
scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_create
scsi_transport_srp: Unknown symbol scsi_is_host_device
WARNING: Error inserting scsi_transport_srp (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/scsi_transport_srp.ko): Unknown symbol in module, or unknown parameter (see dmesg)
ibmvscsic: Unknown symbol scsi_block_requests
ibmvscsic: Unknown symbol scsi_scan_host
ibmvscsic: Unknown symbol scsi_dma_unmap
ibmvscsic: Unknown symbol scsi_add_host_with_dma
ibmvscsic: Unknown symbol scsi_host_put
ibmvscsic: Unknown symbol srp_release_transport
ibmvscsic: Unknown symbol scsi_dma_map
ibmvscsic: Unknown symbol srp_remove_host
ibmvscsic: Unknown symbol srp_attach_transport
ibmvscsic: Unknown symbol scsi_unblock_requests
ibmvscsic: Unknown symbol scsi_remove_host
ibmvscsic: Unknown symbol srp_rport_add
ibmvscsic: Unknown symbol scsi_adjust_queue_depth
ibmvscsic: Unknown symbol scsi_host_alloc
FATAL: Error inserting ibmvscsic (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/ibmvscsi/ibmvscsic.ko): Unknown symbol in module, or unknown parameter (see dmesg)
Creating device nodes with udev
udevd version 128 started
scsi_mod: Unknown ADD relocation: 26
scsi_tgt: Unknown symbol scsi_release_buffers
scsi_tgt: Unknown symbol scsi_host_put
scsi_tgt: Unknown symbol __scsi_put_command
scsi_tgt: Unknown symbol scsi_host_lookup
scsi_tgt: Unknown symbol __scsi_get_command
scsi_tgt: Unknown symbol scsi_init_io
scsi_tgt: Unknown symbol __scsi_alloc_queue
scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_destroy
scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_create
scsi_transport_srp: Unknown symbol scsi_is_host_device
ibmvscsic: Unknown symbol scsi_block_requests
ibmvscsic: Unknown symbol scsi_scan_host
ibmvscsic: Unknown symbol scsi_dma_unmap
ibmvscsic: Unknown symbol scsi_add_host_with_dma
ibmvscsic: Unknown symbol scsi_host_put
ibmvscsic: Unknown symbol srp_release_transport
ibmvscsic: Unknown symbol scsi_dma_map
ibmvscsic: Unknown symbol srp_remove_host
ibmvscsic: Unknown symbol srp_attach_transport
ibmvscsic: Unknown symbol scsi_unblock_requests
ibmvscsic: Unknown symbol scsi_remove_host
ibmvscsic: Unknown symbol srp_rport_add
ibmvscsic: Unknown symbol scsi_adjust_queue_depth
ibmvscsic: Unknown symbol scsi_host_alloc
Boot logging started on /dev/hvc0(/dev/console) at Thu Feb 18 12:38:04 2010
resume device not found (ignoring)
Waiting for device /dev/sda5 to appear: ..............................Could not find /dev/sda5.
Want me to fall back to /dev/sda5? (Y/n)
-- 0:conmux-control -- time-stamp -- Feb/18/10 4:41:54 --
-- 0:conmux-control -- time-stamp -- Feb/18/10 6:00:16 --
(user:ssant@in.ibm.com) connected
Waiting for device /dev/sda5 to appear: ..............................not found -- exiting to /bin/sh
^ permalink raw reply
* Re: [PATCH v4 0/5] PCI: try "pci=use_crs" again
From: Gary Hade @ 2010-02-19 0:58 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Matthew Garrett, Tony Luck, linuxppc-dev, linux-pci, Peter Haight,
Gary Hade, linux-kernel, Jesse Barnes, linux-acpi,
linux-am33-list, Linus Torvalds, Ingo Molnar, Yinghai Lu,
Larry Finger
In-Reply-To: <20100217201654.4013.70201.stgit@bob.kio>
On Wed, Feb 17, 2010 at 01:19:47PM -0700, Bjorn Helgaas wrote:
> Historically, Linux has assumed a single PCI host bridge, with that bridge
> claiming all the address space left after RAM and legacy devices are taken out.
>
> If the system contains multiple host bridges, we can no longer operate under
> that assumption. We have to know what parts of the address space are claimed
> by each bridge so that when we assign resources to a PCI device, we take them
> from a range claimed by the upstream host bridge.
>
> On x86 and ia64, we use ACPI to enumerate all the PCI host bridges in the
> system, and part of the host bridge description is the "_CRS" (current resource
> settings" property, which lists the address space used by the bridge. On x86,
> we currently ignore most of the _CRS information. This patch series changes
> this, so we will use _CRS to learn about the host bridge windows.
>
> Since most x86 machines with multiple host bridges are relatively new, this
> series only turns this on for machines with BIOS dates of 2008 or newer.
I just tried your changes on an IBM x3850 with a 12/01/2008 BIOS
date. After booting without pci=use_crs I observed the expected
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
message. I then loaded 'acpiphp' and was able to successfully
hot-remove and hot-add PCI-X and PCIe cards. Without pci=use_crs
a hot-add operation would have previously caused a machine check.
Tested-by: Gary Hade <garyhade@us.ibm.com>
Gary
--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Anton Blanchard @ 2010-02-19 0:07 UTC (permalink / raw)
To: mel, benh, cl; +Cc: linuxppc-dev
In-Reply-To: <20100218222923.GC31681@kryten>
Hi,
> The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables
> zone reclaim.
FYI even with this enabled I could trip it up pretty easily with a multi
threaded application. I tried running stream across all threads in node 0. The
machine looks like:
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 free: 30254 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 free: 31832 MB
Now create some clean pagecache on node 0:
# taskset -c 0 dd if=/dev/zero of=/tmp/bigfile bs=1G count=16
# sync
node 0 free: 12880 MB
node 1 free: 31830 MB
I built stream to use about 25GB of memory. I then ran stream across all
threads in node 0:
# OMP_NUM_THREADS=16 taskset -c 0-15 ./stream
We exhaust all memory on node 0, and start using memory on node 1:
node 0 free: 0 MB
node 1 free: 20795 MB
ie about 10GB of node 1. Now if we run the same test with one thread:
# OMP_NUM_THREADS=1 taskset -c 0 ./stream
things are much better:
node 0 free: 11 MB
node 1 free: 31552 MB
Interestingly enough it takes two goes to get completely onto node 0, even
with one thread. The second run looks like:
node 0 free: 14 MB
node 1 free: 31811 MB
I had a quick look at the page allocation logic and I think I understand why
we would have issues with multple threads all trying to allocate at once.
- The ZONE_RECLAIM_LOCKED flag allows only one thread into zone reclaim at
a time, and whatever thread is in zone reclaim probably only frees a small
amount of memory. Certainly not enough to satisfy all 16 threads.
- We seem to end up racing between zone_watermark_ok, zone_reclaim and
buffered_rmqueue. Since everyone is in here the memory one thread reclaims
may be stolen by another thread.
I'm not sure if there is an easy way to fix this without penalising other
workloads though.
Anton
^ permalink raw reply
* [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
From: Feng Kan @ 2010-02-18 23:11 UTC (permalink / raw)
To: linux-mtd, linuxppc-dev; +Cc: Feng Kan
This is to lock down the ordering in the correction routine against
the calculate routine. Otherwise, incorrect define would cause ECC errors.
Signed-off-by: Feng Kan <fkan@amcc.com>
Acked-by: Victor Gallardo <vgallardo@amcc.com>
---
drivers/mtd/nand/ndfc.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 40b5658..fc1f0ff 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -102,10 +102,15 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
wmb();
ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
/* The NDFC uses Smart Media (SMC) bytes order */
+#ifdef CONFIG_MTD_NAND_ECC_SMC
ecc_code[0] = p[1];
ecc_code[1] = p[2];
ecc_code[2] = p[3];
+#else
+ ecc_code[0] = p[2];
+ ecc_code[1] = p[1];
+ ecc_code[2] = p[3];
+#endif
return 0;
}
--
1.5.5
^ permalink raw reply related
* [PATCH] gpiolib: Cosmetic improvements for error handling in gpiochip_add()
From: Anton Vorontsov @ 2010-02-18 22:48 UTC (permalink / raw)
To: Andrew Morton
Cc: David Brownell, Dmitry Eremin-Solenikov, linux-kernel,
linuxppc-dev, Bill Gatliff
Hopefully it makes the code look nicer and makes it easier to extend
this function.
Suggested-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Tue, Feb 09, 2010 at 10:16:44AM -0700, Grant Likely wrote:
[...]
> Rather than doing an else block which will need to be reworked if/when
> any additional code is added to the bottom of this routine, please
> rework the if() block to bail on failure instead of implicitly falling
> through to the return statement.
Here it is.
Andrew,
Please either fold this patch into
gpiolib-introduce-chip-addition-removal-notifier.patch
or, actually these changes can stay in its own patch for better
sparation of cosmitc/real changes.
Thanks!
drivers/gpio/gpiolib.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 375c03a..f227c1f 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1099,17 +1099,23 @@ int gpiochip_add(struct gpio_chip *chip)
unlock:
spin_unlock_irqrestore(&gpio_lock, flags);
- if (status == 0)
- status = gpiochip_export(chip);
+
+ if (status)
+ goto fail;
+
+ status = gpiochip_export(chip);
+ if (status)
+ goto fail;
+
+ blocking_notifier_call_chain(&gpio_notifier, GPIO_NOTIFY_CHIP_ADDED,
+ chip);
+
+ return 0;
fail:
/* failures here can mean systems won't boot... */
- if (status)
- pr_err("gpiochip_add: gpios %d..%d (%s) not registered\n",
- chip->base, chip->base + chip->ngpio - 1,
- chip->label ? : "generic");
- else
- blocking_notifier_call_chain(&gpio_notifier,
- GPIO_NOTIFY_CHIP_ADDED, chip);
+ pr_err("gpiochip_add: gpios %d..%d (%s) not registered\n",
+ chip->base, chip->base + chip->ngpio - 1,
+ chip->label ? : "generic");
return status;
}
EXPORT_SYMBOL_GPL(gpiochip_add);
--
1.6.5.7
^ permalink raw reply related
* [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Anton Blanchard @ 2010-02-18 22:29 UTC (permalink / raw)
To: mel, benh, cl; +Cc: linuxppc-dev
I noticed /proc/sys/vm/zone_reclaim_mode was 0 on a ppc64 NUMA box. It gets
enabled via this:
/*
* If another node is sufficiently far away then it is better
* to reclaim pages in a zone before going off node.
*/
if (distance > RECLAIM_DISTANCE)
zone_reclaim_mode = 1;
Since we use the default value of 20 for REMOTE_DISTANCE and 20 for
RECLAIM_DISTANCE it never kicks in.
The local to remote bandwidth ratios can be quite large on System p
machines so it makes sense for us to reclaim clean pagecache locally before
going off node.
The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables
zone reclaim.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/topology.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/topology.h 2010-02-18 14:26:45.736821967 +1100
+++ powerpc.git/arch/powerpc/include/asm/topology.h 2010-02-18 14:51:24.793071748 +1100
@@ -8,6 +8,16 @@ struct device_node;
#ifdef CONFIG_NUMA
+/*
+ * Before going off node we want the VM to try and reclaim from the local
+ * node. It does this if the remote distance is larger than RECLAIM_DISTANCE.
+ * With the default REMOTE_DISTANCE of 20 and the default RECLAIM_DISTANCE of
+ * 20, we never reclaim and go off node straight away.
+ *
+ * To fix this we choose a smaller value of RECLAIM_DISTANCE.
+ */
+#define RECLAIM_DISTANCE 10
+
#include <asm/mmzone.h>
static inline int cpu_to_node(int cpu)
^ permalink raw reply
* [PATCH] powerpc: Call ibm,os-term if the ibm,extended-os-term is present
From: Anton Blanchard @ 2010-02-18 22:11 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
We have had issues in the past with ibm,os-term initiating shutdown of a
partition. This is confusing to the user, especially if panic_timeout is
non zero.
The temporary fix was to avoid calling ibm,os-term if a panic_timeout was set
and since we set it on every boot we basically never call ibm,os-term.
An extended version of ibm,os-term has since been implemented which gives us
the behaviour we want:
"When the platform supports extended ibm,os-term behavior, the return to the
RTAS will always occur unless there is a kernel assisted dump active as
initiated by an ibm,configure-kernel-dump call."
This patch checks for the ibm,extended-os-term property and calls ibm,os-term
if it exists.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-cpumask/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/rtas.c 2010-02-18 20:31:17.283568754 +1100
+++ linux-cpumask/arch/powerpc/kernel/rtas.c 2010-02-19 09:07:05.735254857 +1100
@@ -690,10 +690,14 @@ void rtas_os_term(char *str)
{
int status;
- if (panic_timeout)
- return;
-
- if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
+ /*
+ * Firmware with the ibm,extended-os-term property is guaranteed
+ * to always return from an ibm,os-term call. Earlier versions without
+ * this property may terminate the partition which we want to avoid
+ * since it interferes with panic_timeout.
+ */
+ if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term") ||
+ RTAS_UNKNOWN_SERVICE == rtas_token("ibm,extended-os-term"))
return;
snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
@@ -704,8 +708,7 @@ void rtas_os_term(char *str)
} while (rtas_busy_delay(status));
if (status != 0)
- printk(KERN_EMERG "ibm,os-term call failed %d\n",
- status);
+ printk(KERN_EMERG "ibm,os-term call failed %d\n", status);
}
static int ibm_suspend_me_token = RTAS_UNKNOWN_SERVICE;
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: Convert gef_pic_lock to raw_spinlock
From: Kumar Gala @ 2010-02-18 22:01 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Thomas Gleixner
In-Reply-To: <20100218135727.GA18924@oksana.dev.rtsoft.ru>
On Feb 18, 2010, at 7:57 AM, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, gef_pic_lock has to be a real (non-sleepable) spinlock.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/86xx/gef_pic.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/qe: Convert qe_ic_lock to raw_spinlock
From: Kumar Gala @ 2010-02-18 22:01 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Thomas Gleixner
In-Reply-To: <20100218134312.GA5331@oksana.dev.rtsoft.ru>
On Feb 18, 2010, at 7:43 AM, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, qe_ic_lock has to be a real (non-sleepable) spinlock.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/82xx: Convert pci_pic_lock to raw_spinlock
From: Kumar Gala @ 2010-02-18 22:01 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Thomas Gleixner
In-Reply-To: <20100218135738.GA16072@oksana.dev.rtsoft.ru>
On Feb 18, 2010, at 7:57 AM, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, pci_pic_lock has to be a real (non-sleepable) spinlock.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Convert socrates_fpga_pic_lock to raw_spinlock
From: Kumar Gala @ 2010-02-18 22:01 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Thomas Gleixner
In-Reply-To: <20100218134512.GB5331@oksana.dev.rtsoft.ru>
On Feb 18, 2010, at 7:45 AM, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, socrates_fpga_pic_lock has to be a real =
(non-sleepable)
> spinlock.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>=20
> On Thu, Feb 18, 2010 at 12:22:18PM -0000, Thomas Gleixner wrote:
>> Ben,
>>=20
>> the following patch series is from preempt-rt. It converts the locks
>> which need to be real spinlocks in -rt to raw_spinlocks.
>>=20
>> There is no behaviourial change for !RT kernels because spinlocks and
>> raw_spinlocks are the same on !RT. So for mainline this is a pure
>> annotation while having it in mainline takes the burden of keeping up
>> with the code changes from the RT patch set.
>>=20
>> Please consider to merge into .34.
>=20
> Oh, and I guess the same for the socrates fpga pic...
>=20
> arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 34 =
+++++++++++-----------
> 1 files changed, 17 insertions(+), 17 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [patch 06/15] powerpc: Convert tlbivax_lock to raw_spinlock
From: Kumar Gala @ 2010-02-18 21:52 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev
In-Reply-To: <20100218122000.354221871@linutronix.de>
On Feb 18, 2010, at 6:22 AM, Thomas Gleixner wrote:
> tlbivax_lock needs to be a real spinlock in RT. Convert it to
> raw_spinlock.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/powerpc/mm/tlb_nohash.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
From: Albrecht Dreß @ 2010-02-18 18:45 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, devicetree-discuss, ben-linux, iws
In-Reply-To: <OFC412BED7.5D5934A3-ONC12576CE.005D5F44-C12576CE.005EBE55@transmode.se>
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
Hi Joakim:
Am 18.02.10 18:14 schrieb(en) Joakim Tjernlund:
> > [snip]
> > > > static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> > > > {
> > > > - writeccr(i2c, 0);
> > > > - udelay(30);
> > > > - writeccr(i2c, CCR_MEN);
> > > > - udelay(30);
> > > > - writeccr(i2c, CCR_MSTA | CCR_MTX);
> > > > - udelay(30);
> > > > - writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > > > - udelay(30);
> > > > - writeccr(i2c, CCR_MEN);
> > > > - udelay(30);
> > > > + int k;
> > > > + u32 delay_val = 1000000 / i2c->real_clk + 1;
> > > > +
> > > > + if (delay_val < 2)
> > > > + delay_val = 2;
> > > > +
> > > > + for (k = 9; k; k--) {
> > > > + writeccr(i2c, 0);
> > > > + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > > > + udelay(delay_val);
> > > > + writeccr(i2c, CCR_MEN);
> > > > + udelay(delay_val << 1);
> > > > + }
> > > > }
> > >
>>> I am curious, didn't old method work with by just wrapping a for(k=9; k; k--) around it? How did the wave form look?
> >
>> Sure does that work! The waveform was somewhat "streched", mainly due to the delays between some of the writeccr() calls which don't change the sda/scl lines. Unfortunately I didn't take shots from the scope.
>
> Yeah, the long delays has to go. So the wave form was the same but more stretched in time? I ask because I don't understand the writeccr(i2c, CCR_MSTA | CCR_MTX); is supposed to do.
Afaict, this is really a no-op. The '5200 user's manual says about MEN
<snip>
* 0 module is reset and disabled. This is the Power-ON reset. When low the interface is held in reset, but registers can still be accessed.
* 1 I2C module is enabled. Bit must be set before other CR bits have any effect.
</snip>
The change in the MSTA is needed -with the proper delays- as to generate the START and STOP conditions.
Unfortunately, the data sheet is not very clear (or my English too bad), but reading it *after* seeing the signals on the scope, I can at least guess what they mean :-/
Thus, the old code will probably produce SDA and SCL held high for ~90us, then a SDA/SCL low for ~30us (plus/minus the delays the hw adds internally according to the clock setting), and then a ~30us SDA/SCL high. It is not possible to get the necessary delays from the data sheet, but as I said I empirically verified some cases to be safe.
> The old code only works when the device is stuck at the last bit. To cope with any bit (worst case is the first bit) you need 9 cycles, 8 bits + ack = 9
>
> Just toggling the clock 9 cycles should unlock any slave stuck in a read operation. To unlock slaves stuck in a write operation you also need to generate a START in every cycle too.
Yes, of course... this was the initial motivation of the patch, as I *have* a slave which sometimes needs more than one cycle!
> As far as I can tell your patch does all of the above so
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Thanks a lot again for your time, and your helpful comments!
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
From: Joakim Tjernlund @ 2010-02-18 18:07 UTC (permalink / raw)
To: Grant Likely
Cc: glikely, iws, Albrecht Dreß, devicetree-discuss,
linuxppc-dev, ben-linux
In-Reply-To: <fa686aa41002180941y71201b27y64905fe34cc56deb@mail.gmail.com>
glikely@secretlab.ca wrote on 2010/02/18 18:41:40:
>
> On Thu, Feb 18, 2010 at 10:14 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > "Albrecht Dre=DF" <albrecht.dress@arcor.de> wrote on 2010/02/18 16:=
04:16:
> > As far as I can tell your patch does all of the above so
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Thanks Joakim. On a point of process; "Signed-off-by" means that
> you've actually handled the patch and forwarded it on, either by
> reposting or putting it in a git tree for someone to pull. The
> Signed-off-by trail collects a history of all the people who have
> touched a patch during its development and merging.
>
> Reviewers can use Acked-by: or Reviewed-by: to indicate their consent=
.
> Ben can add your annotation when he merges the patch into his i2c
> tree.
I see, then please change that to
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Thanks,
Jocke=
^ permalink raw reply
* Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
From: Grant Likely @ 2010-02-18 17:41 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: linuxppc-dev, Albrecht Dreß, devicetree-discuss, ben-linux,
iws
In-Reply-To: <OFC412BED7.5D5934A3-ONC12576CE.005D5F44-C12576CE.005EBE55@transmode.se>
On Thu, Feb 18, 2010 at 10:14 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> "Albrecht Dre=DF" <albrecht.dress@arcor.de> wrote on 2010/02/18 16:04:16:
> As far as I can tell your patch does all of the above so
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Thanks Joakim. On a point of process; "Signed-off-by" means that
you've actually handled the patch and forwarded it on, either by
reposting or putting it in a git tree for someone to pull. The
Signed-off-by trail collects a history of all the people who have
touched a patch during its development and merging.
Reviewers can use Acked-by: or Reviewed-by: to indicate their consent.
Ben can add your annotation when he merges the patch into his i2c
tree.
Cheers,
g.
^ permalink raw reply
* Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
From: Joakim Tjernlund @ 2010-02-18 17:14 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev, devicetree-discuss, ben-linux, iws
In-Reply-To: <2921453.1266505456809.JavaMail.ngmail@webmail09.arcor-online.net>
"Albrecht Dre=DF" <albrecht.dress@arcor.de> wrote on 2010/02/18 16:04:1=
6:
>
> Hi Joakim:
>
> [snip]
> > > static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> > > {
> > > - writeccr(i2c, 0);
> > > - udelay(30);
> > > - writeccr(i2c, CCR_MEN);
> > > - udelay(30);
> > > - writeccr(i2c, CCR_MSTA | CCR_MTX);
> > > - udelay(30);
> > > - writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > > - udelay(30);
> > > - writeccr(i2c, CCR_MEN);
> > > - udelay(30);
> > > + int k;
> > > + u32 delay_val =3D 1000000 / i2c->real_clk + 1;
> > > +
> > > + if (delay_val < 2)
> > > + delay_val =3D 2;
> > > +
> > > + for (k =3D 9; k; k--) {
> > > + writeccr(i2c, 0);
> > > + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > > + udelay(delay_val);
> > > + writeccr(i2c, CCR_MEN);
> > > + udelay(delay_val << 1);
> > > + }
> > > }
> >
> > I am curious, didn't old method work with by just wrapping
> > a for(k=3D9; k; k--) around it? How did the wave form look?
>
> Sure does that work! The waveform was somewhat "streched", mainly du=
e to the
> delays between some of the writeccr() calls which don't change the sd=
a/scl
> lines. Unfortunately I didn't take shots from the scope.
Yeah, the long delays has to go. So the wave form was the same but more=
stretched
in time? I ask because I don't understand the writeccr(i2c, CCR_MSTA | =
CCR_MTX);
is supposed to do.
>
> However, for *one* cycle, the old code needed (only counting the udel=
ay's) 150
> us. For 9 cycles, it's 1.35 ms, which isn't really nice ;-). At 375=
kHz real
> clock rate, delay_val is 3, i.e. each cycle consumes 9 us, or 81 us f=
or the
> whole fixup procedure. If the clock is slower, the gain is of course=
a lot
> smaller, and at 20.5 kHz each cycle again needs 150 us...
>
> My feeling is that the delays used in the old code are just "some" va=
lues
> which work for sure, to if you like, my change is basically optimisat=
ion...
The old code only works when the device is stuck at the last bit. To co=
pe
with any bit (worst case is the first bit) you need 9 cycles, 8 bits + =
ack =3D 9
Just toggling the clock 9 cycles should unlock any slave stuck in a rea=
d operation.
To unlock slaves stuck in a write operation you also need to generate a=
START in
every cycle too.
As far as I can tell your patch does all of the above so
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> BTW, related to your earlier question, I checked the timings recorded=
with the
> scope at 100 and at 20 kHz against the nxp's "I2C bus specification a=
nd user
> manual", rev. 03 - everything seems to be fine.
Good, thanks.
Jocke=
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Peter Zijlstra @ 2010-02-18 17:08 UTC (permalink / raw)
To: Joel Schopp; +Cc: Michael Neuling, ego, linuxppc-dev, Ingo Molnar, linux-kernel
In-Reply-To: <4B7D6AAB.5080602@austin.ibm.com>
On Thu, 2010-02-18 at 10:28 -0600, Joel Schopp wrote:
> > There's one fundamental assumption, and one weakness in the
> > implementation.
> >
> I'm going to guess the weakness is that it doesn't adjust the cpu power
> so tasks running in SMT1 mode actually get more than they account for?
No, but you're right, if these SMTx modes are running at different
frequencies then yes that needs to happen as well.
The weakness is failing to do the right thing in the presence of a
'strategically' placed RT task.
Suppose:
Sibling0, Sibling1, Sibling2, Sibling3
idle OTHER OTHER FIFO
it might not manage to migrate a task to 0 because it ends up selecting
3 as busiest. It doesn't at all influence RT placement, but it does look
at nr_running (which does include RT tasks)
> What's the assumption?
That cpu_of(Sibling n) < cpu_of(Sibling n+1)
^ permalink raw reply
* Re: [PATCH] powerpc/82xx: Convert pci_pic_lock to raw_spinlock
From: Thomas Gleixner @ 2010-02-18 16:35 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100218135738.GA16072@oksana.dev.rtsoft.ru>
On Thu, 18 Feb 2010, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, pci_pic_lock has to be a real (non-sleepable) spinlock.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: Convert gef_pic_lock to raw_spinlock
From: Thomas Gleixner @ 2010-02-18 16:35 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100218135727.GA18924@oksana.dev.rtsoft.ru>
On Thu, 18 Feb 2010, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, gef_pic_lock has to be a real (non-sleepable) spinlock.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Convert socrates_fpga_pic_lock to raw_spinlock
From: Thomas Gleixner @ 2010-02-18 16:33 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100218134512.GB5331@oksana.dev.rtsoft.ru>
On Thu, 18 Feb 2010, Anton Vorontsov wrote:
> Interrupt controllers' hooks are executed in the atomic context, so
> they are not permitted to sleep (with RT kernels non-raw spinlocks are
> sleepable). So, socrates_fpga_pic_lock has to be a real (non-sleepable)
> spinlock.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox