Re: [PATCH 0/5] arm64: vdso: getcpu() support

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1561 bytes --]

On Fri, Jun 05, 2020 at 02:11:26PM +0100, Mark Brown wrote:

> It is questionable if something TPIDRRO_EL0 based is worthwhile at all
> on current kernels, since v4.18 we have had support for restartable
> sequences which can be used to provide a sched_getcpu() implementation
> with generally better performance than the vDSO approach on
> architectures which have that[1].  Work is ongoing to implement this for
> glibc:

...

> This is currently not compatible with KPTI due to what Will suggests is
> a misunderstanding on my part about the use of TPIDRRO_EL0 by the KPTI
> trampoline, since this posting is mainly for discussion of the approach
> as a whole and Will only just mentioned this that's not been addressed
> here.

So, I've been looking into this.  While it is true that we can do the
reinitialization I'm not sure that it's sensible to add this to what's
already a hot path where we're taking a substantial overhead for KPTI.
Given that once RSEQ sched_getcpu() support is merged into glibc (and
hopefully also other libcs) the majority of users will use that rather
than a vDSO implementation and the overwhelming impact will be overhead
until systems with E0PD start to be widely deployed which doesn't seem
great.

If we could find another scratch register for the trampoline that'd be
fine but otherwise I'm really questioning the value.  I've looked and
didn't see anything but it's entirely possible I'm missing something.
Otherwise do people think this is an idea worth pursuing, or should we
just suggest that people use RSEQ instead?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel