Re: [PATCh 0/3] x86,tlb: context switch optimizations

[Rik van Riel]

On Thu, 2024-11-14 at 10:52 +0100, Ingo Molnar wrote:
> 
> * Rik van Riel <riel@xxxxxxxxxxx> wrote:
> 
> > On Wed, 13 Nov 2024 10:55:50 +0100
> > Borislav Petkov <bp@xxxxxxxxx> wrote:
> > 
> > > On Fri, Nov 08, 2024 at 07:27:47PM -0500, Rik van Riel wrote:
> > > > While profiling switch_mm_irqs_off with several workloads,
> > > > it appears there are two hot spots that probably don't need
> > > > to be there.  
> > > 
> > > One of those three is causing the below here, zapping them from
> > > tip.
> > > 
> > 
> > TL;DR: __text_poke ends up sending IPIs with interrupts disabled.
> > 
> > > [    3.186469]  on_each_cpu_cond_mask+0x50/0x90
> > > [    3.186469]  flush_tlb_mm_range+0x1a8/0x1f0
> > > [    3.186469]  ? cpu_bugs_smt_update+0x14/0x1f0
> > > [    3.186469]  __text_poke+0x366/0x5d0
> > 
> > Here is an alternative to avoid __text_poke() from calling
> > on_each_cpu_cond_mask() with IRQs disabled:
> > 
> > ---8<---
> > From e872edeaad14c793036f290afc28000281e1b76a Mon Sep 17 00:00:00
> > 2001
> > From: Rik van Riel <riel@xxxxxxxxxxx>
> > Date: Wed, 13 Nov 2024 09:51:16 -0500
> > Subject: [PATCH] x86/alternatives: defer poking_mm TLB flush to
> > next use
> 
> I'd argue *both* of your patches improve the code, right?
> 

We have 3 possible solutions, and I think we only need one of them.

> Mind sending an updated series? It might not make it into the merge
> window,
> but these look like good changes to me.

I would be happy to send a new series, but it would be good if
we agreed on what solution we wanted :)

1) Move the interrupt re-enabling up (probably not this one?)

2) Explicitly clear the mm_cpumask bit in unuse_temporary_mm()

3) Have unuse_temporary_mm increment the mm's tlb_gen, since that
   is the only thing flush_tlb_mm_range really does for an MM
   without any bits set in the mm_cpumask.

Which one would you guys prefer?

-- 
All Rights Reversed.