Re: [RFC] [PATCH] lazy TLB: possible bug, some notes (2.3.12)

Linus Torvalds (torvalds@transmeta.com)
30 Jul 1999 20:24:40 GMT


In article <37A1E209.9375559@colorfullife.com>,
Manfred Spraul <manfreds@colorfullife.com> wrote:
>
>1) I've attached a small patch which should fix 2 possible
>problems on the i386.
>* mm->cpu_vm_mask was not set on crossing TLB flushes.
>* there was a race in flush_tlb_current_task() between setting
>mm->cpu_vm_mask and the IPI which could modify cpu_vm_mask.
>
>Since flush_tlb_current_task() is now identical to
>flush_tlb_mm(current->mm), I'd remove flush_tlb_current_task()
>and change the macro for flush_tlb(). [in include/asm/pgtable.h]

If you have the same code, then you have slow code. There's a
fundamental difference between "flush current" and "flush an mm that
may not exist on this CPU at all".

You're right about cpu_vm_mask being set in the wrong order, though.

>2) I think it should be possible to call start_lazy_tlb()
>even if the thread is already in the lazy-tlb mode.

Why? That would be a no-op, so the caller might as well just do

if (current->mm)
start_lazy_tlb();

rather than making start_lazy_tlb() do something that is not
appropriate.

>3) I noticed that 2.3.12 breaks the PPC mm implementation:
>mmu_context_overflow() assumes that it can get to all
>mm's by looking at tsk->mm for all tasks in the system.
>(arch/ppc/mm/init.c)

The PPC mm implementation probably doesn't compile in 2.3.12 because of
the changes.

For those kinds of things, though, it should be possible to just use
"active_mm" instead. The lazy TLB handling needs more than that change
to work (right now I have patches for alpha and sparc pending, so it's
not _too_ hard, but it can get involved).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/