Does this seem a reasonable thing to do? The patch isn't tested but you
should get the idea.
p.
--- clean/linux/arch/arm/mm/proc-sa110.S Tue Jan 12 13:48:12 1999
+++ linux/arch/arm/mm/proc-sa110.S Fri Jan 15 11:20:42 1999
@@ -238,6 +238,7 @@
stmfd sp!, {r4 - r9, fp, lr} @ Store most regs on stack
mrs ip, cpsr
stmfd sp!, {ip} @ Save cpsr_SVC
+ ldr r2, [r0, #TSS_MEMMAP] @ Get old page tables
str sp, [r0, #TSS_SAVE] @ Save sp_SVC
ldr sp, [r1, #TSS_SAVE] @ Get saved sp_SVC
ldr r0, [r1, #TSK_ADDR_LIMIT]
@@ -246,6 +247,16 @@
movne r0, #DOM_USERDOMAIN
mcr p15, 0, r0, c3, c0 @ Set segment
ldr r0, [r1, #TSS_MEMMAP] @ Page table pointer
+ /* Flushing the cache is nightmarishly slow, so we take
+ any excuse to get out of it. If the old page table
+ is the same as the new, this is a CLONE_VM relative
+ of the old task and there is no need to flush. The
+ overhead of the tests isn't even on the radar compared to
+ the cost of the flush itself. */
+ /* @@ In future we could also check for the new task being
+ a kernel thread. */
+ teq r0, r2 @ Same pagetables?
+ beq 2f
ldr r3, =Lclean_switch
ldr r2, [r3]
ands r2, r2, #1
@@ -262,7 +273,7 @@
mcr p15, 0, r1, c7, c10, 4 @ drain WB
mcr p15, 0, r0, c2, c0, 0 @ load page table pointer
mcr p15, 0, r1, c8, c7, 0 @ flush TLBs
- ldmfd sp!, {ip}
+2: ldmfd sp!, {ip}
msr spsr, ip @ Save tasks CPSR into SPSR
for this return
ldmfd sp!, {r4 - r9, fp, pc}^ @ Load all regs saved
previously
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
