Re: tlb_gather_mmu() and semantics of "fullmm"

David Miller
2009-03-27T04:57:20Z

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 27 Mar 2009 09:33:44 +1100

> > I'd be surprised if there are still such optimizations to be made:
> > maybe a whole different strategy could be more efficient, but I'd be
> > surprised if there's really a superfluous TLB flush to be tweaked away.
> >
> > Although it looks as if there's a TLB flush at the end of every batch,
> > isn't that deceptive (on x86 anyway)? I'm thinking that the first
> > flush_tlb_mm() will end up calling leave_mm(), and the subsequent
> > ones do nothing because the cpu_vm_mask is then empty.
>
> Ok, well, that's a bit different on other archs like powerpc where we virtually
> never remove bits from cpu_vm_mask... (though we probably could... to be looked
> at).

We do this on sparc64 when the mm->mm_users == 1 and 'mm' is the
current->active_mm

See arch/sparc/kernel/smp_64.c:smp_flush_tlb_pending() where we go:

if (mm == current->active_mm && atomic_read(&mm->mm_users) == 1)
mm->cpu_vm_mask = cpumask_of_cpu(cpu);
else
smp_cross_call_masked(&xcall_flush_tlb_pending,
ctx, nr, (unsigned long) vaddrs,
&mm->cpu_vm_mask);

__flush_tlb_pending(ctx, nr, vaddrs);