* Re: [PATCH] ppc32: remove secondary_ti
2008-11-16 21:43 [PATCH] ppc32: remove secondary_ti Milton Miller
@ 2008-11-16 20:26 ` Benjamin Herrenschmidt
2008-11-17 7:46 ` Milton Miller
0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2008-11-16 20:26 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, paulus
On Sun, 2008-11-16 at 15:43 -0600, Milton Miller wrote:
> Instead of copying current_set[cpu] to secondary_ti, directly index into
> current_set by the cpu number like head_64.S. In addition to removing
> the variable, a slow to respond cpu will not clobber another cpus
> stack.
Except that we don't know our CPU number at this stage do we ? IE. r24
is our HW number, is it guaranteed to be what we want to index
current_set ?
Ben.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] ppc32: remove secondary_ti
@ 2008-11-16 21:43 Milton Miller
2008-11-16 20:26 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 3+ messages in thread
From: Milton Miller @ 2008-11-16 21:43 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Instead of copying current_set[cpu] to secondary_ti, directly index into
current_set by the cpu number like head_64.S. In addition to removing
the variable, a slow to respond cpu will not clobber another cpus
stack.
---
grep found no other reference in arch/powerpc. compile tested but I have
no 32bit smp hardware.
Index: next.git/arch/powerpc/kernel/head_32.S
===================================================================
--- next.git.orig/arch/powerpc/kernel/head_32.S 2008-11-16 01:36:45.000000000 -0600
+++ next.git/arch/powerpc/kernel/head_32.S 2008-11-16 01:42:02.000000000 -0600
@@ -906,10 +906,11 @@ __secondary_start:
bl init_idle_6xx
#endif /* CONFIG_6xx */
- /* get current_thread_info and current */
- lis r1,secondary_ti@ha
+ /* get current_thread_info (current_set[cpu]) and current = */
+ slwi r1,r24,2
+ addis r1,r1,current_set@ha
tophys(r1,r1)
- lwz r1,secondary_ti@l(r1)
+ lwz r1,current_set@l(r1)
tophys(r2,r1)
lwz r2,TI_TASK(r2)
Index: next.git/arch/powerpc/kernel/smp.c
===================================================================
--- next.git.orig/arch/powerpc/kernel/smp.c 2008-11-16 01:36:05.000000000 -0600
+++ next.git/arch/powerpc/kernel/smp.c 2008-11-16 01:36:22.000000000 -0600
@@ -58,7 +58,6 @@
#endif
int smp_hw_index[NR_CPUS];
-struct thread_info *secondary_ti;
cpumask_t cpu_possible_map = CPU_MASK_NONE;
cpumask_t cpu_online_map = CPU_MASK_NONE;
@@ -320,7 +319,6 @@ int __cpuinit __cpu_up(unsigned int cpu)
{
int c;
- secondary_ti = current_set[cpu];
if (!cpu_enable(cpu))
return 0;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ppc32: remove secondary_ti
2008-11-16 20:26 ` Benjamin Herrenschmidt
@ 2008-11-17 7:46 ` Milton Miller
0 siblings, 0 replies; 3+ messages in thread
From: Milton Miller @ 2008-11-17 7:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
On Nov 16, 2008, at 2:26 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2008-11-16 at 15:43 -0600, Milton Miller wrote:
>> Instead of copying current_set[cpu] to secondary_ti, directly index
>> into
>> current_set by the cpu number like head_64.S. In addition to removing
>> the variable, a slow to respond cpu will not clobber another cpus
>> stack.
>
> Except that we don't know our CPU number at this stage do we ? IE. r24
> is our HW number, is it guaranteed to be what we want to index
> current_set ?
No, you are right, current_set is ordered by logical cpu id.
We could search the hwcpuid array similar to our search of the paca on
ppc64. But for now go ahead and reject this patch.
milton
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-11-17 7:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-16 21:43 [PATCH] ppc32: remove secondary_ti Milton Miller
2008-11-16 20:26 ` Benjamin Herrenschmidt
2008-11-17 7:46 ` Milton Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox