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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html