Re: Potential race in TLB flush batching?

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andy Lutomirski <luto@kernel.org>, Mel Gorman <mgorman@suse.de>
Cc: Nadav Amit <nadav.amit@gmail.com>, linux-mm@kvack.org
Subject: Re: Potential race in TLB flush batching?
Date: Fri, 14 Jul 2017 17:00:41 +1000	[thread overview]
Message-ID: <1500015641.2865.81.camel@kernel.crashing.org> (raw)
In-Reply-To: <CALCETrXvkF3rxLijtou3ndSxG9vu62hrqh1ZXkaWgWbL-wd+cg@mail.gmail.com>

On Tue, 2017-07-11 at 15:07 -0700, Andy Lutomirski wrote:
> On Tue, Jul 11, 2017 at 12:18 PM, Mel Gorman <mgorman@suse.de> wrote:
> 
> I would change this slightly:
> 
> > +void flush_tlb_batched_pending(struct mm_struct *mm)
> > +{
> > +A A A A A A  if (mm->tlb_flush_batched) {
> > +A A A A A A A A A A A A A A  flush_tlb_mm(mm);
> 
> How about making this a new helper arch_tlbbatch_flush_one_mm(mm);
> The idea is that this could be implemented as flush_tlb_mm(mm), but
> the actual semantics needed are weaker.A  All that's really needed
> AFAICS is to make sure that any arch_tlbbatch_add_mm() calls on this
> mm that have already happened become effective by the time that
> arch_tlbbatch_flush_one_mm() returns.

Jumping in ... I just discovered that 'new' batching stuff... is it
documented anywhere ?

We already had some form of batching via the mmu_gather, now there's a
different somewhat orthogonal and it's completely unclear what it's
about and why we couldn't use what we already had. Also what
assumptions it makes if I want to port it to my arch....

The page table management code was messy enough without yet another
undocumented batching mechanism that isn't quite the one we already
had...

Ben.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>