[RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Kumar Gala]

Posting this to get any review and suggestions on the functionality of the
patch.

Questions/issues:
* what to do about the stack_ovf check in entry_32.S
* do we really have any constraints on ppc32 (beyond being in lowmem) on
the locations of the stacks [see irqstack_early_init()]

- k

diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index a86d8d8..2cf72d2 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -118,7 +118,6 @@ config XMON_DISASSEMBLY

 config IRQSTACKS
 	bool "Use separate kernel stacks when processing interrupts"
-	depends on PPC64
 	help
 	  If you say Y here the kernel will use separate kernel stacks
 	  for handling hard and soft interrupts.  This can help avoid
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 425616f..ad40eb4 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -352,7 +352,7 @@ void __init init_IRQ(void)
 {
 	if (ppc_md.init_IRQ)
 		ppc_md.init_IRQ();
-#ifdef CONFIG_PPC64
+#ifdef CONFIG_IRQSTACKS
 	irq_ctx_init();
 #endif
 }
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 92ccc6f..89aaaa6 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -32,6 +32,31 @@

 	.text

+#ifdef CONFIG_IRQSTACKS
+_GLOBAL(call_do_softirq)
+	mflr	r0
+	stw	r0,4(r1)
+	stwu	r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
+	mr	r1,r3
+	bl	__do_softirq
+	lwz	r1,0(r1)
+	lwz	r0,4(r1)
+	mtlr	r0
+	blr
+
+_GLOBAL(call_handle_irq)
+	mflr	r0
+	stw	r0,4(r1)
+	mtctr	r6
+	stwu	r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r5)
+	mr	r1,r5
+	bctrl
+	lwz	r1,0(r1)
+	lwz	r0,4(r1)
+	mtlr	r0
+	blr
+#endif /* CONFIG_IRQSTACKS */
+
 /*
  * This returns the high 64 bits of the product of two 64-bit numbers.
  */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 36f6779..ebd1b1d 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -16,6 +16,7 @@
 #include <linux/root_dev.h>
 #include <linux/cpu.h>
 #include <linux/console.h>
+#include <linux/lmb.h>

 #include <asm/io.h>
 #include <asm/prom.h>
@@ -229,6 +230,28 @@ int __init ppc_init(void)

 arch_initcall(ppc_init);

+#ifdef CONFIG_IRQSTACKS
+static void __init irqstack_early_init(void)
+{
+	unsigned int i;
+
+	/*
+	 * interrupt stacks must be under 256MB, we cannot afford to take
+	 * SLB misses on them.
+	 */
+	for_each_possible_cpu(i) {
+		softirq_ctx[i] = (struct thread_info *)
+			__va(lmb_alloc_base(THREAD_SIZE,
+					    THREAD_SIZE, 0x10000000));
+		hardirq_ctx[i] = (struct thread_info *)
+			__va(lmb_alloc_base(THREAD_SIZE,
+					    THREAD_SIZE, 0x10000000));
+	}
+}
+#else
+#define irqstack_early_init()
+#endif
+
 /* Warning, IO base is not yet inited */
 void __init setup_arch(char **cmdline_p)
 {
@@ -286,6 +309,8 @@ void __init setup_arch(char **cmdline_p)
 	init_mm.end_data = (unsigned long) _edata;
 	init_mm.brk = klimit;

+	irqstack_early_init();
+
 	/* set up the bootmem stuff with available memory */
 	do_init_bootmem();
 	if ( ppc_md.progress ) ppc_md.progress("setup_arch: bootmem", 0x3eab);

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Benjamin Herrenschmidt]

On Thu, 2008-04-24 at 00:37 -0500, Kumar Gala wrote:
> +       /*
> +        * interrupt stacks must be under 256MB, we cannot afford to
> take
> +        * SLB misses on them.
> +        */
> +       for_each_possible_cpu(i) {
> +               softirq_ctx[i] = (struct thread_info *)
> +                       __va(lmb_alloc_base(THREAD_SIZE,
> +                                           THREAD_SIZE, 0x10000000));
> +               hardirq_ctx[i] = (struct thread_info *)
> +                       __va(lmb_alloc_base(THREAD_SIZE,
> +                                           THREAD_SIZE, 0x10000000));
> +       }
> +

The comment is a bit bogus :-) (about SLB misses). lowmem is your limit
I think. Also, why not share the code with ppc64 ?

Ben.

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Kumar Gala]

On Apr 24, 2008, at 2:18 AM, Benjamin Herrenschmidt wrote:
>
> On Thu, 2008-04-24 at 00:37 -0500, Kumar Gala wrote:
>> +       /*
>> +        * interrupt stacks must be under 256MB, we cannot afford to
>> take
>> +        * SLB misses on them.
>> +        */
>> +       for_each_possible_cpu(i) {
>> +               softirq_ctx[i] = (struct thread_info *)
>> +                       __va(lmb_alloc_base(THREAD_SIZE,
>> +                                           THREAD_SIZE,  
>> 0x10000000));
>> +               hardirq_ctx[i] = (struct thread_info *)
>> +                       __va(lmb_alloc_base(THREAD_SIZE,
>> +                                           THREAD_SIZE,  
>> 0x10000000));
>> +       }
>> +
>
> The comment is a bit bogus :-) (about SLB misses). lowmem is your  
> limit
> I think. Also, why not share the code with ppc64 ?

I'm going to change it to be just lmb_alloc() so it will be difficult  
to share with ppc64 (other than w/an ifdef).

- k

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Benjamin Herrenschmidt]

On Thu, 2008-04-24 at 07:59 -0500, Kumar Gala wrote:
> I'm going to change it to be just lmb_alloc() so it will be difficult  
> to share with ppc64 (other than w/an ifdef).

Unless we change lmb_alloc to just be an lmb_alloc_base with 0 and have
the later do the right thing ?

You don't put highmem in the LMBs ? If you do, we do need to have the
max lowmem there no ?

Ben.

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Kumar Gala]

On Apr 24, 2008, at 9:53 AM, Benjamin Herrenschmidt wrote:
>
> On Thu, 2008-04-24 at 07:59 -0500, Kumar Gala wrote:
>> I'm going to change it to be just lmb_alloc() so it will be difficult
>> to share with ppc64 (other than w/an ifdef).
>
> Unless we change lmb_alloc to just be an lmb_alloc_base with 0 and  
> have
> the later do the right thing ?

don't follow.  Look at the "real" patch and comment on that.

> You don't put highmem in the LMBs ? If you do, we do need to have the
> max lowmem there no ?

we restrict lmb alloc via LMB_REAL_LIMIT in include/asm-powerpc/lmb.h

- k

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Christoph Hellwig]

On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote:
>  config IRQSTACKS
>  	bool "Use separate kernel stacks when processing interrupts"
> -	depends on PPC64

Why do we have this as a user-selectable option?  It should be on by
default on 32 or 64bit.

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Benjamin Herrenschmidt]

On Fri, 2008-04-25 at 09:23 +0200, Christoph Hellwig wrote:
> On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote:
> >  config IRQSTACKS
> >  	bool "Use separate kernel stacks when processing interrupts"
> > -	depends on PPC64
> 
> Why do we have this as a user-selectable option?  It should be on by
> default on 32 or 64bit.

History maybe ? In the early days it was a bit "experimental" (we had a
couple of issues that popped up with some thread flags not being
properly recovered etc...). Nowadays, I agree it should not be an
option.

Ben.

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Kumar Gala]

On Apr 25, 2008, at 8:03 AM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-04-25 at 09:23 +0200, Christoph Hellwig wrote:
>> On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote:
>>> config IRQSTACKS
>>> 	bool "Use separate kernel stacks when processing interrupts"
>>> -	depends on PPC64
>>
>> Why do we have this as a user-selectable option?  It should be on by
>> default on 32 or 64bit.
>
> History maybe ? In the early days it was a bit "experimental" (we  
> had a
> couple of issues that popped up with some thread flags not being
> properly recovered etc...). Nowadays, I agree it should not be an
> option.

for some reason I felt that it was pretty much required on ppc64 when  
I did the port over to ppc32.

Do we think we want to poke Paul to get this in for v2.6.26 so we can  
get it some more testing on all the ppc32 systems?

- k

Re: [RFC][WIP][PATCH] Add IRQSTACKS to ppc32

[Paul Mackerras]

Kumar Gala writes:

> Do we think we want to poke Paul to get this in for v2.6.26 so we can  
> get it some more testing on all the ppc32 systems?

It's not going in 2.6.26, since it's a pretty substantial change and
it was first seen half-way through the merge window...

Paul.