: load_mmu for SMP systems
PATCH 1/1 : load_mmu for SMP systems
In SMP systems, each CPU needs to set up "current_cpu_data.tlbsize". Some CPUs do this initialization in cpu_probe, which is called both by init_arch and start_secondary. However, some CPUs do this in their TLB setup code, which is called via load_mmu. The SMP boot code doesn't currently call load_mmu() for the secondary CPUs. Here's a simple fix for the 2.4 tree.
TLB flush routines that have loops running up to tlbsize will lose if it's not set properly on all CPUs!
Kip
Index: arch/mips/kernel/smp.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/smp.c,v retrieving revision 1.10.2.24
mips/kernel/smp.c +1 -0
@@ -99,6 +99,7 @@unsigned int cpu =smp_processor_id ();cpu_probe (); +load_mmu ();prom_init_secondary ();per_cpu_trap_init ();
Index: arch/mips64/kernel/smp.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/smp.c,v retrieving revision 1.26.2.22
mips64/kernel/smp.c +1 -0
@@ -103,6 +103,7 @@unsigned int cpu =smp_processor_id ();cpu_probe (); +load_mmu ();prom_init_secondary ();per_cpu_trap_init ();
OK, I'll add some declarations make it tidier.
Kip
Quoted 10 lines · Kip Walker
In SMP systems, each CPU needs to set up "current_cpu_data.tlbsize". Some CPUs do this initialization in
cpu_probe, which is called both byinit_archandstart_secondary. However, some CPUs do this in their TLB setup code, which is called viaload_mmu. The SMP boot code doesn't currently callload_mmu()for the secondary CPUs. Here's a simple fix for the 2.4 tree.TLB flush routines that have loops running up to tlbsize will lose if it's not set properly on all CPUs!
Index: arch/mips/kernel/smp.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/smp.c,v retrieving revision 1.10.2.24
mips/kernel/smp.c +4 -0
@@ -39,6 +39,9 @@#include <asm/mmu_context.h> #include <asm/smp.h> +extern void load_mmu (void ); +extern void per_cpu_trap_init (void ); +/* The 'big kernel lock' */ spinlock_t kernel_flag __cacheline_aligned_in_smp = SPIN_LOCK_UNLOCKED;int smp_threads_ready;/* Not used */
@@ -99,6 +102,7 @@unsigned int cpu =smp_processor_id ();cpu_probe (); +load_mmu ();prom_init_secondary ();per_cpu_trap_init ();
Index: arch/mips64/kernel/smp.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/smp.c,v retrieving revision 1.26.2.22
mips64/kernel/smp.c +4 -0
@@ -39,6 +39,9 @@#include <asm/mmu_context.h> #include <asm/smp.h> +extern void load_mmu (void ); +extern void per_cpu_trap_init (void ); +/* The 'big kernel lock' */ spinlock_t kernel_flag __cacheline_aligned_in_smp = SPIN_LOCK_UNLOCKED;int smp_threads_ready;/* Not used */
@@ -103,6 +106,7 @@unsigned int cpu =smp_processor_id ();cpu_probe (); +load_mmu ();prom_init_secondary ();per_cpu_trap_init ();
Quoted 6 lines · Kip Walker
In SMP systems, each CPU needs to set up "current_cpu_data.tlbsize". Some CPUs do this initialization in
cpu_probe, which is called both byinit_archandstart_secondary. However, some CPUs do this in their TLB setup code, which is called viaload_mmu. The SMP boot code doesn't currently callload_mmu()for the secondary CPUs. Here's a simple fix for the 2.4 tree.
I instead changed cpu-probe to set tlbsize properly. Nothing wrong with your patch, it just fits better into my Grand Plan (TM) :-)
Quoted 2 lines
TLB flush routines that have loops running up to tlbsize will lose if it's not set properly on all CPUs!
Yeah, they're going to be sort of slow. There must be a reason for all those GHz processors ;-)
Ralf
Quoted 6 lines · Ralf Baechle
Quoted 3 lines
TLB flush routines that have loops running up to tlbsize will lose if it's not set properly on all CPUs!
Yeah, they're going to be sort of slow. There must be a reason for all those GHz processors ;-)
Um, it was worse than that if (for example) a complete TLB flush has a "for (i=0; i<0; i++)" loop around it. My board was experiencing occasional userland segfaults thanks to bogus TLB flushing.
Kip