linux-next: manual merge of the tip tree with the sparc tree

linux-next: manual merge of the tip tree with the sparc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/sparc/kernel/smp_32.c between commit d6d048192b1d ("sparc32:
implement SMP IPIs using the generic functions") from the sparc tree and
commit 184748cc50b2 ("sched: Provide scheduler_ipi() callback in response
to smp_send_reschedule()") from the tip tree.

I fixed it up (I am pretty sure that the sparc tree patch supercedes the
tip tree one) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux-next: manual merge of the tip tree with the sparc tree

[Daniel Hellstrom]

Stephen Rothwell wrote:

>Hi all,
>
>Today's linux-next merge of the tip tree got a conflict in
>arch/sparc/kernel/smp_32.c between commit d6d048192b1d ("sparc32:
>implement SMP IPIs using the generic functions") from the sparc tree and
>commit 184748cc50b2 ("sched: Provide scheduler_ipi() callback in response
>to smp_send_reschedule()") from the tip tree.
>
>I fixed it up (I am pretty sure that the sparc tree patch supercedes the
>tip tree one) and can carry the fix as necessary.
>  
>
Thanks for noticing this.

I looked at linux-next and I think the call to the scheduler_ipi is 
missing in the resched interrupt routine. I believe that the below patch 
should be applied ontop of linux-next. Could you include it in the merge 
or what do you suggest I do?

Thanks,
Daniel


diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
index 41102c5..d5b3958 100644
--- a/arch/sparc/kernel/smp_32.c
+++ b/arch/sparc/kernel/smp_32.c
@@ -156,11 +156,11 @@ void arch_send_call_function_ipi_mask(const struct 
cpumask *mask)

 void smp_resched_interrupt(void)
 {
+       irq_enter();
+       scheduler_ipi();
        local_cpu_data().irq_resched_count++;
-       /*
-        * do nothing, since it all was about calling re-schedule
-        * routine called by interrupt return code.
-        */
+       irq_exit();
+       /* re-schedule routine called by interrupt return code. */
 }

 void smp_call_function_single_interrupt(void)

Re: linux-next: manual merge of the tip tree with the sparc tree

[Peter Zijlstra]

On Thu, 2011-05-19 at 15:37 +0200, Daniel Hellstrom wrote:


> diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
> index 41102c5..d5b3958 100644
> --- a/arch/sparc/kernel/smp_32.c
> +++ b/arch/sparc/kernel/smp_32.c
> @@ -156,11 +156,11 @@ void arch_send_call_function_ipi_mask(const struct 
> cpumask *mask)
> 
>  void smp_resched_interrupt(void)
>  {
> +       irq_enter();
> +       scheduler_ipi();
>         local_cpu_data().irq_resched_count++;
> -       /*
> -        * do nothing, since it all was about calling re-schedule
> -        * routine called by interrupt return code.
> -        */
> +       irq_exit();
> +       /* re-schedule routine called by interrupt return code. */
>  }

That doesn't look like an IPI, that looks like its calls the function on
the local cpu, which is completely pointless.

Re: linux-next: manual merge of the tip tree with the sparc tree

[Daniel Hellstrom]

Peter Zijlstra wrote:

>On Thu, 2011-05-19 at 15:37 +0200, Daniel Hellstrom wrote:
>
>
>  
>
>>diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
>>index 41102c5..d5b3958 100644
>>--- a/arch/sparc/kernel/smp_32.c
>>+++ b/arch/sparc/kernel/smp_32.c
>>@@ -156,11 +156,11 @@ void arch_send_call_function_ipi_mask(const struct 
>>cpumask *mask)
>>
>> void smp_resched_interrupt(void)
>> {
>>+       irq_enter();
>>+       scheduler_ipi();
>>        local_cpu_data().irq_resched_count++;
>>-       /*
>>-        * do nothing, since it all was about calling re-schedule
>>-        * routine called by interrupt return code.
>>-        */
>>+       irq_exit();
>>+       /* re-schedule routine called by interrupt return code. */
>> }
>>    
>>
>
>That doesn't look like an IPI, that looks like its calls the function on
>the local cpu, which is completely pointless.
>  
>
The above function is one of the IPI interrupt handlers.

The smp_send_reschedule() is called by the generic code, it is 
responsible for sending an IRQ to the target CPU, that CPU comes into 
smp_resched_interrupt above from the IRQ trap handler. So yes, the 
scheduler_ipi() is called on the local CPU, but on the CPU taking the 
IPI not the CPU sending the IPI.

Daniel

Re: linux-next: manual merge of the tip tree with the sparc tree

[Peter Zijlstra]

On Fri, 2011-05-20 at 08:07 +0200, Daniel Hellstrom wrote:
> Peter Zijlstra wrote:
> 
> >On Thu, 2011-05-19 at 15:37 +0200, Daniel Hellstrom wrote:
> >
> >
> >  
> >
> >>diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
> >>index 41102c5..d5b3958 100644
> >>--- a/arch/sparc/kernel/smp_32.c
> >>+++ b/arch/sparc/kernel/smp_32.c
> >>@@ -156,11 +156,11 @@ void arch_send_call_function_ipi_mask(const struct 
> >>cpumask *mask)
> >>
> >> void smp_resched_interrupt(void)
> >> {
> >>+       irq_enter();
> >>+       scheduler_ipi();
> >>        local_cpu_data().irq_resched_count++;
> >>-       /*
> >>-        * do nothing, since it all was about calling re-schedule
> >>-        * routine called by interrupt return code.
> >>-        */
> >>+       irq_exit();
> >>+       /* re-schedule routine called by interrupt return code. */
> >> }
> >>    
> >>
> >
> >That doesn't look like an IPI, that looks like its calls the function on
> >the local cpu, which is completely pointless.
> >  
> >
> The above function is one of the IPI interrupt handlers.
> 
> The smp_send_reschedule() is called by the generic code, it is 
> responsible for sending an IRQ to the target CPU, that CPU comes into 
> smp_resched_interrupt above from the IRQ trap handler. So yes, the 
> scheduler_ipi() is called on the local CPU, but on the CPU taking the 
> IPI not the CPU sending the IPI.

Ah, clearly I cannot read well, I actually thought that was
smp_send_reschedule(). OK, if sparc32 is now actually sending IPIs and
the above is the handler, then you're completely right, sorry for the
confusion.

Also, since sparc32 now grew this IPI, you can remove:

+++ b/init/Kconfig
@@ -827,6 +827,11 @@ config SCHED_AUTOGROUP
          desktop applications.  Task group autogeneration is currently based
          upon task session.
 
+config SCHED_TTWU_QUEUE
+       bool
+       depends on !SPARC32
+       default y
+
 config MM_OWNER
        bool
 

Re: linux-next: manual merge of the tip tree with the sparc tree

[Daniel Hellstrom]

Peter Zijlstra wrote:

>On Fri, 2011-05-20 at 08:07 +0200, Daniel Hellstrom wrote:
>  
>
>>Peter Zijlstra wrote:
>>
>>    
>>
>>>On Thu, 2011-05-19 at 15:37 +0200, Daniel Hellstrom wrote:
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
>>>>index 41102c5..d5b3958 100644
>>>>--- a/arch/sparc/kernel/smp_32.c
>>>>+++ b/arch/sparc/kernel/smp_32.c
>>>>@@ -156,11 +156,11 @@ void arch_send_call_function_ipi_mask(const struct 
>>>>cpumask *mask)
>>>>
>>>>void smp_resched_interrupt(void)
>>>>{
>>>>+       irq_enter();
>>>>+       scheduler_ipi();
>>>>       local_cpu_data().irq_resched_count++;
>>>>-       /*
>>>>-        * do nothing, since it all was about calling re-schedule
>>>>-        * routine called by interrupt return code.
>>>>-        */
>>>>+       irq_exit();
>>>>+       /* re-schedule routine called by interrupt return code. */
>>>>}
>>>>   
>>>>
>>>>        
>>>>
>>>That doesn't look like an IPI, that looks like its calls the function on
>>>the local cpu, which is completely pointless.
>>> 
>>>
>>>      
>>>
>>The above function is one of the IPI interrupt handlers.
>>
>>The smp_send_reschedule() is called by the generic code, it is 
>>responsible for sending an IRQ to the target CPU, that CPU comes into 
>>smp_resched_interrupt above from the IRQ trap handler. So yes, the 
>>scheduler_ipi() is called on the local CPU, but on the CPU taking the 
>>IPI not the CPU sending the IPI.
>>    
>>
>
>Ah, clearly I cannot read well, I actually thought that was
>smp_send_reschedule(). OK, if sparc32 is now actually sending IPIs and
>the above is the handler, then you're completely right, sorry for the
>confusion.
>  
>
Yes, my patches implements IPI for sparc32.

>Also, since sparc32 now grew this IPI, you can remove:
>
>+++ b/init/Kconfig
>@@ -827,6 +827,11 @@ config SCHED_AUTOGROUP
>          desktop applications.  Task group autogeneration is currently based
>          upon task session.
> 
>+config SCHED_TTWU_QUEUE
>+       bool
>+       depends on !SPARC32
>+       default y
>+
>  
>

Do you think this is an acceptable patch? If so I will send these two 
patches to the sparclinux list unless you think otherwise.

Thank you for enlightening this,
Daniel


Subject: [PATCH] SCHED_TTWU_QUEUE is not longer needed since sparc32 now 
implements IPI

Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
Reported-by: Peter Zijlstra <peterz@infradead.org>
---
 init/Kconfig   |    5 -----
 kernel/sched.c |    2 +-
 2 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index df64627..a66b656 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -827,11 +827,6 @@ config SCHED_AUTOGROUP
          desktop applications.  Task group autogeneration is currently 
based
          upon task session.

-config SCHED_TTWU_QUEUE
-       bool
-       depends on !SPARC32
-       default y
-
 config MM_OWNER
        bool

diff --git a/kernel/sched.c b/kernel/sched.c
index c62acf4..0516af4 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2564,7 +2564,7 @@ static void ttwu_queue(struct task_struct *p, int cpu)
 {
        struct rq *rq = cpu_rq(cpu);

-#if defined(CONFIG_SMP) && defined(CONFIG_SCHED_TTWU_QUEUE)
+#if defined(CONFIG_SMP)
        if (sched_feat(TTWU_QUEUE) && cpu != smp_processor_id()) {
                ttwu_queue_remote(p, cpu);
                return;
--

Re: linux-next: manual merge of the tip tree with the sparc tree

[Peter Zijlstra]

On Fri, 2011-05-20 at 14:48 +0200, Daniel Hellstrom wrote:
> Subject: [PATCH] SCHED_TTWU_QUEUE is not longer needed since sparc32 now implements IPI
> 
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
> Reported-by: Peter Zijlstra <peterz@infradead.org>

Yep, this looks fine, please merge this patch through whatever tree
carries the sparc32-smp work.

Acked-by: Peter Zijlstra <peterz@infradead.org>

> ---
>  init/Kconfig   |    5 -----
>  kernel/sched.c |    2 +-
>  2 files changed, 1 insertions(+), 6 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index df64627..a66b656 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -827,11 +827,6 @@ config SCHED_AUTOGROUP
>           desktop applications.  Task group autogeneration is currently 
> based
>           upon task session.
> 
> -config SCHED_TTWU_QUEUE
> -       bool
> -       depends on !SPARC32
> -       default y
> -
>  config MM_OWNER
>         bool
> 
> diff --git a/kernel/sched.c b/kernel/sched.c
> index c62acf4..0516af4 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -2564,7 +2564,7 @@ static void ttwu_queue(struct task_struct *p, int cpu)
>  {
>         struct rq *rq = cpu_rq(cpu);
> 
> -#if defined(CONFIG_SMP) && defined(CONFIG_SCHED_TTWU_QUEUE)
> +#if defined(CONFIG_SMP)
>         if (sched_feat(TTWU_QUEUE) && cpu != smp_processor_id()) {
>                 ttwu_queue_remote(p, cpu);
>                 return;
> -- 

Re: linux-next: manual merge of the tip tree with the sparc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Hi Daniel,

On Thu, 19 May 2011 15:37:59 +0200 Daniel Hellstrom <daniel@gaisler.com> wrote:
>
> I looked at linux-next and I think the call to the scheduler_ipi is 
> missing in the resched interrupt routine. I believe that the below patch 
> should be applied ontop of linux-next. Could you include it in the merge 
> or what do you suggest I do?

That patch (if correct) needs to be applied to some tree, linux-next just
takes what it is given.  That patch is really beyond a merge fix as that
code exists on neither tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

linux-next: manual merge of the tip tree with the sparc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/sparc/include/asm/topology_64.h between commit acc455cffa75
("sparc64: Setup sysfs to mark LDOM sockets, cores and threads
correctly") from the sparc tree and commit 06931e622468
("sched/topology: Rename topology_thread_cpumask() to
topology_sibling_cpumask()") from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/sparc/include/asm/topology_64.h
index d1761df5cca6,9a928fcb7a9b..000000000000
--- a/arch/sparc/include/asm/topology_64.h
+++ b/arch/sparc/include/asm/topology_64.h
@@@ -40,8 -40,8 +40,8 @@@ static inline int pcibus_to_node(struc
  #ifdef CONFIG_SMP
  #define topology_physical_package_id(cpu)	(cpu_data(cpu).proc_id)
  #define topology_core_id(cpu)			(cpu_data(cpu).core_id)
 -#define topology_core_cpumask(cpu)		(&cpu_core_map[cpu])
 +#define topology_core_cpumask(cpu)		(&cpu_core_sib_map[cpu])
- #define topology_thread_cpumask(cpu)		(&per_cpu(cpu_sibling_map, cpu))
+ #define topology_sibling_cpumask(cpu)		(&per_cpu(cpu_sibling_map, cpu))
  #endif /* CONFIG_SMP */
  
  extern cpumask_t cpu_core_map[NR_CPUS];

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]