lkml.org 
[lkml]   [2023]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector
    Date
    Heiko Stuebner <heiko@sntech.de> writes:

    > From: Heiko Stuebner <heiko.stuebner@vrull.eu>
    >
    > The hwprobing infrastructure was merged recently [0] and contains a
    > mechanism to probe both extensions but also microarchitecural features
    > on a per-core level of detail.
    >
    > While discussing the solution internally we identified some possible issues,
    > tried to understand the underlying issue and come up with a solution for it.
    > All these deliberations overlapped with hwprobing being merged, but that
    > shouldn't really be an issue, as both have their usability - see below.
    > Also please see the "Things to consider" at the bottom!
    >
    >
    > Possible issues:
    > - very much limited to Linux
    > - schedulers run processes on all cores by default, so will need
    > the common set of extensions in most cases

    ...which hwprobe has support for via the CPU mask. no?

    > - each new extensions requires an uapi change, requiring at least
    > two pieces of software to be changed
    > - adding another extension requires a review process (only known
    > extensions can be exposed to user-space)
    > - vendor extensions have special needs and therefore possibly
    > don’t fit well
    >
    >
    > Limited to Linux:
    > -----------------
    >
    > The syscall and its uapi is Linux-specific and other OSes probably
    > will not defer to our review process and requirements just to get
    > new bits in. Instead most likely they'll build their own systems,
    > leading to fragmentation.

    There are a number of examples where multiple OSs have followed what
    Linux does, and vice versa. I'd say the opposite -- today system
    builders do not do their own solution, but review what's out there and
    mimics existing ones.

    Personally I think this argument is moot, and will not matter much for
    fragmentation.

    > Feature on all cores:
    > ---------------------
    >
    > Arnd previously ([1]) commented in the discussion, that there
    > should not be a need for optimization towards hardware with an
    > asymmetric set of features. We believe so as well, especially
    > when talking about an interface that helps processes to identify
    > the optimized routines they can execute.
    >
    > Of course seeing it with this finality might not take into account
    > the somewhat special nature of RISC-V, but nevertheless it describes
    > the common case for programs very well.
    >
    > For starters the scheduler in its default behaviour, will try to use any
    > available core, so the standard program behaviour will always need the
    > intersection of available extensions over all cores.
    >
    >
    > Limiting program execution to specific cores will likely always be a
    > special use case and already requires Linux-specific syscalls to
    > select the set of cores.
    >
    > So while it can come in handy to get per-core information down the road
    > via the hwprobing interface, most programs will just want to know if
    > they can use a extension on just any core.
    >
    >
    > Review process:
    > ---------------
    >
    > There are so many (multi-letter-)extensions already with even more in
    > the pipeline. To expose all of them, each will require a review process
    > and uapi change that will make defining all of them slow as the
    > kernel needs patching after which userspace needs to sync in the new
    > api header.
    >
    >
    > Vendor-extensions:
    > ------------------
    >
    > Vendor extensions are special in their own right.
    > Userspace probably will want to know about them, but we as the kernel
    > don't want to care about them too much (except as errata), as they're
    > not part of the official RISC-V ISA spec.
    >
    > Getting vendor extensions from the dt to userspace via hwprobe would
    > require coordination efforts and as vendors have the tendency to invent
    > things during their development process before trying to submit changes
    > upstream this likely would result in conflicts with assigned ids down
    > the road. Which in turn then may create compatibility-issues with
    > userspace builds built on top of the mainline kernel or a pre-
    > existing vendor kernel.
    >
    > The special case also is that vendor A could in theory implement an
    > extension from vendor B. So this would require to actually assign
    > separate hwprobe keys to vendors (key for xthead extensions, key for
    > xventana extensions, etc). This in turn would require vendors to
    > come to the mainline kernel to get assigned a key (which in reality
    > probably won't happen), which would then make the kernel community
    > sort of an id authority.
    >
    >
    >
    >
    > To address these, the attached patch series adds a second interface
    > for the common case and "just" exposes the isa-string via the
    > AT_BASE_PLATFORM aux vector.

    *A second interface* introduced the second hwprobe landed. Really?
    Start a discussion on how to extend hwprobe instead.


    Björn

    \
     
     \ /
      Last update: 2023-05-01 21:55    [W:8.380 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site