Re: [PATCH v3 05/11] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm
From: Borislav Petkov
Date: Fri Jun 23 2017 - 04:42:47 EST
On Thu, Jun 22, 2017 at 11:08:38AM -0700, Andy Lutomirski wrote:
> Yes, I agree it's confusing. There really are three numbers. Those
> numbers are: the latest generation, the generation that this CPU has
> caught up to, and the generation that the requester of the flush we're
> currently handling has asked us to catch up to. I don't see a way to
> reduce the complexity.
Yeah, can you pls put that clarification what what is, over it. It
explains it nicely what the check is supposed to do.
> >> The flush IPI hits after a switch_mm_irqs_off() call notices the
> >> change from 1 to 2. switch_mm_irqs_off() will do a full flush and
> >> increment the local tlb_gen to 2, and the IPI handler for the partial
> >> flush will see local_tlb_gen == mm_tlb_gen - 1 (because local_tlb_gen
> >> == 2 and mm_tlb_gen == 3) and do a partial flush.
> > Why, the 2->3 flush has f->end == TLB_FLUSH_ALL.
> > That's why you have this thing in addition to the tlb_gen.
> Yes. The idea is that we only do remote partial flushes when it's
> 100% obvious that it's safe.
So why wouldn't my simplified suggestion work then?
if (f->end != TLB_FLUSH_ALL &&
mm_tlb_gen == local_tlb_gen + 1)
1->2 is a partial flush - gets promoted to a full one
2->3 is a full flush - it will get executed as one due to the f->end setting to
> It could be converted to two full flushes or to just one, I think,
> depending on what order everything happens in.
Right. One flush at the right time would be optimal.
> But this approach of using three separate tlb_gen values seems to
> cover all the bases, and I don't think it's *that* bad.
As I said in IRC, let's document that complexity then so that when we
stumble over it in the future, we at least know why it was done this
Good mailing practices for 400: avoid top-posting and trim the reply.