Skip to contentSkip to conversation

: load_mmu for SMP systems

PATCH In review Kip Walker 2 participants 4 messages Apr 25, 2003 – Apr 28, 2003 MIPS

lore
Share & tools
lore

Kip Walker

author
#0 lore raw

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
diff -u -r1.10.2.24 smp.c
@@ -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
diff -u -r1.26.2.22 smp.c
@@ -103,6 +103,7 @@
 	unsigned int cpu = smp_processor_id();
 
 	cpu_probe();
+	load_mmu();
 	prom_init_secondary();
 	per_cpu_trap_init();
 
author
#1 lore raw

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 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!

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
diff -u -r1.10.2.24 smp.c
@@ -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
diff -u -r1.26.2.22 smp.c
@@ -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();
 
#2 lore raw
In reply to Kip Walker
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 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.

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

author
#3 lore raw
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