Re: active_mm & SMP & TLB flush: possible bug

Re: active_mm & SMP & TLB flush: possible bug

[Manfred Spraul]

>> 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".
>> >From my first impression, it's a CPU specific information
>> (every CPU has exactly one active_mm, threads which are not running have
>> no
>> active_mm), so I'd have used a global array[NR_CPUS].
>
>That soulds like a good idea -- care to offer a patch? =)

I still try to understand the current implementation, and I can't propose a
patch before I understand the current code...

I'll try to write a patch over the weekend.


    Manfred





--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: active_mm & SMP & TLB flush: possible bug

[Manfred Spraul, Benjamin C.R. LaHaise]

>> 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".
>> >From my first impression, it's a CPU specific information
>> (every CPU has exactly one active_mm, threads which are not running have
>> no
>> active_mm), so I'd have used a global array[NR_CPUS].
>
>That soulds like a good idea -- care to offer a patch? =)

I know you should not reply twice to one mail, but I noticed that my initial
assumption was wrong:
It seems that the MMU caches can contain data from multiple
"struct mm_struct"'s on the PPC cpu, perhaps this also applies to
other CPU's.
It's Intel specific that the TLB contains data from just one mm_struct.


--
    Manfred


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: active_mm & SMP & TLB flush: possible bug

[Kanoj Sarcar]

> 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".

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.

> >From my first impression, it's a CPU specific information
> (every CPU has exactly one active_mm, threads which are not running have
> no
> active_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

> 
> 
> 	Manfred
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: active_mm & SMP & TLB flush: possible bug

[Benjamin C.R. LaHaise]

On Wed, 28 Jul 1999, Manfred Spraul wrote:

> 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).

> 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".
> >From my first impression, it's a CPU specific information
> (every CPU has exactly one active_mm, threads which are not running have
> no
> active_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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

active_mm & SMP & TLB flush: possible bug

[Manfred Spraul]

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 because
current->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".
>From my first impression, it's a CPU specific information
(every CPU has exactly one active_mm, threads which are not running have
no
active_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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/