active_mm & SMP & TLB flush: possible bug
I think that active_mm breaks CLEVER_SMP_INVALIDATE (linux/asm-i386/pgtable.h)
(version 2.3.11)
e.g. flush_tlb():
CPU 1 executes thread A, CPU2 waits in
the idle thread with a lazy TLB context of thread A.
CPU1: flush_tlb() causes no IPI becausecurrent->mm->mm_users is still 1.
if these 2 CPU switch their roles, then we use an outdates TLB cache.
-------------
BTW, where can I find more details about the active_mm implementation? specifically, I'd like to know why active_mm was added to "struct task_struct".
Quoted 1 line
From my first impression, it's a CPU specific information
(every CPU has exactly one active_mm, threads which are not running have noactive_mm), so I'd have used a global array[NR_CPUS].
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 2 lines · Manfred Spraul
if these 2 CPU switch their roles, then we use an outdates TLB cache.
You're right, thankfully it's fixed in 2.3.12-8 (meaning that my dual finally stops SIGSEGVing random processes).
Quoted 7 lines
BTW, where can I find more details about the
active_mmimplementation? specifically, I'd like to know whyactive_mmwas added to "structtask_struct".Quoted 1 line
From my first impression, it's a CPU specific information
(every CPU has exactly one
active_mm, threads which are not running have noactive_mm), so I'd have used a global array[NR_CPUS].
That soulds like a good idea -- care to offer a patch? =)
-ben
--
Hi! I'm Signature Virus 99! Copy me into your .signature and join the fun!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 3 lines
BTW, where can I find more details about the
active_mmimplementation? specifically, I'd like to know whyactive_mmwas added to "structtask_struct".
That goes for a lot of other changes in 2.3 - unfortunately, there seems to be no concept of release notes etc, that provide one liner descriptions of the changes being put into a release.
In this case at least, the concept of "active_mm" reduces tlb flushes when switching *to* a kernel thread, since a kernel thread has no user level translations, and can use the kernel-level translations of the previous thread. set_mmu_context updates the task.cr3, which is checked in __switch_to, and since the cr3 update is skipped, the tlb's are not flushed.
Quoted 4 lines
Quoted 1 line
From my first impression, it's a CPU specific information
(every CPU has exactly one
active_mm, threads which are not running have noactive_mm), so I'd have used a global array[NR_CPUS].
Umm, really? My reading of the code was that all kernel threads and exitted user threads had no "mm", and had an "active_mm" only while executing on the cpu. Other user threads with user level translations always have an "mm" and "active_mm".
Kanoj
Quoted 8 lines
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/