Re: [RFC v2 7/9] x86/mm: Introduce Remote Action Request

[Rik van Riel <riel@surriel.com>]

On Tue, 2025-05-20 at 23:26 +0300, Nadav Amit wrote:
> 
> > On 20 May 2025, at 16:00, Rik van Riel <riel@surriel.com> wrote:
> > 
> > > Putting aside the rest of the code, I see you don’t call
> > > should_flush_tlb().
> > > I think it is worth mentioning in commit log or comment the
> > > rationale
> > > behind
> > > it (and maybe benchmarks to justify it).
> > > 
> > > 
> > The long term plan here is to simply have the originating
> > CPU included in the cpumask, and have it send a RAR
> > request to itself.
> 
> That’s unrelated. I was referring to considering supporting
> some sort of lazy TLB to eliminate sending RAR to cores that
> do not care about it. Is there a cost of RAR to more cores than
> needed? My guess is that there is one, and maybe in such cases
> you would want actual IPI and special handling.

For RAR, I suspect the big cost is waking up
CPUs in idle states, and waiting for them to
wake up.

One possibility may be to change leave_mm()
to have an argument to set some flag that
the RAR code can read to see whether or
not to send a RAR interrupt to that CPU,
even if it is in the cpumask.

I don't think we can use the exact same
should_flush_tlb() logic, because the
tlb_gen is not updated by a RAR flush,
and the should_flush_tlb() logic is
somewhat intertwined with the tlb_gen
logic.

-- 
All Rights Reversed.