Re: [PATCH 1/7] stop_machine: Introduce stop_machine_nmi()

[Borislav Petkov]

On Wed, Jan 28, 2026 at 01:31:44AM +0000, Kaplan, David wrote:
> Ok, that's what I thought you were suggesting.  But as I noted, I don't
> think that works if CONFIG_SMP=n because stop_machine.c isn't built.
> 
> I think you could fix this by adding an #ifdef CONFIG_SMP in the header and
> a dummy definition of stop_machine_nmi_handler_enabled in that case, but is
> it worth adding another #ifdef/#else/#endif just to move the static key
> declaration?

That's already there:

#else	/* CONFIG_SMP || CONFIG_HOTPLUG_CPU */
...

static __always_inline bool stop_machine_nmi_handler_enabled(void)
{
        return false;
}

:-)

That's the usual pattern with those things.

But we might not need it anymore.

> I think that can also work, but just curious why that would be preferred?

Simpler code.

> It seems very similar in theory (test a bit to see if the handler hasn't
> been run yet on this cpu and if so clear it and run the handler).  It might
> be slightly less memory usage (I think) but creates more cache contention
> with every core trying to modify the one nmi_cpumask value.

We don't care about performance with stomp_machine, right? It is a big fat
hammer and bouncing a cacheline in the face of NMIs firing on every core is
probably meh...

> And while the perf of any stop machine isn't meant to be the best, we still
> don't want the NMI handler to run longer than it has to and having hundreds
> of cores fighting over the same cacheline to clear their bit doesn't seem
> ideal.

I'd say let's make the simplest variant work first and then go optimize it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette