Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface

[enh <enh@google.com>]

On Thu, Feb 15, 2024 at 7:49 AM Evan Green <evan@rivosinc.com> wrote:
>
> On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
> >
> >
> >
> > On 14/02/24 11:31, Evan Green wrote:
> > >
> > > This series illustrates the use of a recently accepted Linux syscall that
> > > enumerates architectural information about the RISC-V cores the system
> > > is running on. In this series we expose a small wrapper function around
> > > the syscall. An ifunc selector for memcpy queries it to see if unaligned
> > > access is "fast" on this hardware. If it is, it selects a newly provided
> > > implementation of memcpy that doesn't work hard at aligning the src and
> > > destination buffers.
> > >
> > > For applications and libraries outside of glibc that want to use
> > > __riscv_hwprobe() in ifunc selectors, this series also sends a pointer
> > > to the riscv_hwprobe() function in as the second argument to ifunc
> > > selectors. A new inline convenience function can help application and
> > > library callers to check for validity and quickly probe a single key.
> >
> > I still think we should address Jessica Clarke remarks for the ifunc ABI [1].
> > I recall that Florian has tried to address the ifunc ordering and that
> > Jessica proposed solutions was not fully sufficient to address all the
> > ifunc corner cases.
> >
> > [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html
>
> I haven't invested the time yet in studying the resolver to understand
> how feasible Jessica's suggestion is. I was sort of hoping Florian
> would chime in with an "oh yeah let's do that" or "no, it doesn't
> work". I suppose I still am :)

certainly on Android we looked at the amount of work that would
require (and the likely slowdown to dynamic linking, which is already
problematic for us, given that it's a large component of app launch
time that our zygote trick can't magic away) and decided that we're
unlikely to do it, even though in principle it's a nice idea.

> Alternatively, patches 1-3 of this series stand on their own. If the
> ifunc aspect of this is gated on me doing a bunch of research, it
> might at least make sense to land the first half now, to get Linux
> users easy access to the __riscv_hwprobe() syscall and vDSO.
>
> -Evan