[PATCH RT v2 0/3] riscv: add PREEMPT_RT support

[Evan Green]

On Mon, Nov 6, 2023 at 12:53 AM Sebastian Andrzej Siewior
<bigeasy at linutronix.de> wrote:
>
> On 2023-11-03 11:22:40 [-0700], Evan Green wrote:
> > > I don't know what it does and how often it needs to be done. The
> > > question is would it be okay to do once on system boot or does it need
> > > to be done each time the CPU goes up? Is it required to be the first
> > > thing it does or can it be delayed to slightly later point in time?
> >
> > It's essentially a characterization we do on each CPU to figure out if
> > misaligned word accesses are fast or slow. This info is reported to
> > usermode, and potentially has kernel consumers as well (Charlie's ip
> > checksumming series wants to flip a static branch based on it).
>
> So you need to do this on each CPU? And there may be differences between
> CPU0 and CPU1? On x86 for instance all CPUs within one socket behave the
> same. I'm not aware that different CPUs on sockets within a system are
> supported.
>
> > In a sense I barely need the buffer, the buffer is just a runway I use
> > to do dummy memcpys across. I need to do it once on boot for each CPU,
> > and for any additional CPUs that show up via hotplug. It does not need
> > to be done across suspend/resume.
> >
> > The patch in question was an attempt to move this work to be done in
> > parallel, since on systems with lots of CPUs, doing it serially in
> > smp_callin() was causing boot time regressions.
> >
> > For boot, I think the plan I outlined should work: allocate all pages
> > in the initcall before calling on_each_cpu(). For hotplug, I'll have
> > to find a spot to allocate a buffer before the CPU comes up, so it can
> > use it in smp_callin().
>
> My question still remains: Is this needed to be done on each CPU in the
> system or would one CPU, the boot CPU, be sufficient? The static branch
> you mentioned is not per-CPU basis this is per system. If you hook
> this check to CPU-hotplug, then this will happen for instance during
> suspend/ resume (of if triggered manually) and the CPU "feature" will
> likely not change.
>
> As naive as I am, I would assume that doing this on the boot CPU should
> be enough.

I don't think it's safe to assume all cores will be the same. With the
proliferation of big.LITTLE-esque designs (even I thought on Intel),
and the likelihood of even greater variety on an architecture like
risc-v, I think it makes sense to do the measurement on each core. You
are correct that in the ip checksum static branch, we can only take
the path optimized for misaligned loads if all cores support it.

The goal is to measure all CPUs in parallel at boot, and then measure
any new hotplugged CPUs as they arrive. You're right that across
suspend/resume or other times when we don't expect the CPU to change
out from under us, we should avoid re-measuring. My parallel patch
aims for that, though there could still be issues.
-Evan