Enabling the V Extension for Linux Userspace by Default

[Palmer Dabbelt]

Andy recently posted Linux patches to enable the V extension
<https://lore.kernel.org/all/20230509103033.1...@sifive.com/>.
There's still some minor comments, but it's looking pretty likely this
will end up in the next Linux release.

That leaves the question of what to do with the default state of the V
extension. As Bjorn summarized on the glibc list
<https://inbox.sourceware.org/libc-alpha/87leinq...@all.your.base.are.belong.to.us/>,
turning on the V extension constitutes a uABI break -- at least one in
theory, it's unclear if anything will actually break in practice.

The polarity of the default value in Kconfig is still up for debate
<https://lore.kernel.org/all/20230509-chitchat-elitism-bc4882a8ef8d@spud/>.
Regardless of what ends up in defconfig, though, distributions will need
to decide how risk tolerant they are WRT the ABI break and set their
kernel configs accordingly.

I think that's probably a per-distro decision and thus better done on
those lists, but happy to talk here if folks have anything more general.

[Sean Halle]

Thanks Palmer, good update :-)

One thing.. would there be a way to give a sort of crisp list of the implications of "V extension turned on by default"?

For example:

- what will happen when a distro is run on silicon that does not implement V?  Without knowing more about the mechanism under the hood, the first reaction is: it will break, and the distro will be unusable or it will trap to m-mode..  is that right?  If not, could you say a bit about the mechanism that allows binaries that have V instructions to be run on silicon that does not implement V?   

In the case of m-mode trap.. that.. seems almost the same thing as breaking, no?  The slow down is likely to be.. impressive.. no?  In m-mode trap there does not seem to be opportunity to software pipeline or the other compiler techniques that provide decent FP performance..  and high overhead to analyze the V instruction complexities.. and high overhead to maintain the vector mode state across the different processes that all share the same m-mode trap..  and hypervisor complexities that also much be handled in the trap..  a trap really seems like a bad idea to rely on..

Honestly.. "V on by default" sounds quite scary..  could you say a bit more detail of the exact mechanics that will avoid both breaking and avoid significant slowdown on silicon without V?

Thanks Palmer,

Sean

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/mhng-c1a1120c-d447-4845-ac16-f50fd8205975%40palmer-ri-x1c9a.

[Palmer Dabbelt]

On Mon, 15 May 2023 00:53:16 PDT (-0700), sean...@gmail.com wrote:
> Thanks Palmer, good update :-)
>
> One thing.. would there be a way to give a sort of crisp list of the
> implications of "V extension turned on by default"?

There's some linked threads, that's the best description anyone could
come up with at the time. If you've got more questions though I'm happy
to answer them.

Broadly speaking the implications are pretty deep into systems land,
though: on by default means a risk of the ABI break (as described in the
glibc thread), off by default means userspace needs to call the prctl.

> For example:
> - what will happen when a distro is run on silicon that does not implement
> V? Without knowing more about the mechanism under the hood, the first
> reaction is: it will break, and the distro will be unusable or it will trap
> to m-mode.. is that right? If not, could you say a bit about the
> mechanism that allows binaries that have V instructions to be run on
> silicon that does not implement V?

(see below about M-mode traps)

That's really a distro question, as most of the V dependencies are in
userspace. So if the distro wants to build code that assumes the V
extension (or any other extension) that will result in images that don't
run on systems that lack V (or any other required extension). We try
hard in SW land to make sure distros have the option to be compatible,
but it's always possible to skip those.

> In the case of m-mode trap.. that.. seems almost the same thing as
> breaking, no? The slow down is likely to be.. impressive.. no? In m-mode
> trap there does not seem to be opportunity to software pipeline or the
> other compiler techniques that provide decent FP performance.. and high
> overhead to analyze the V instruction complexities.. and high overhead to
> maintain the vector mode state across the different processes that all
> share the same m-mode trap.. and hypervisor complexities that also much be
> handled in the trap.. a trap really seems like a bad idea to rely on..

That's also up to vendors, though more of a HW vendor thing this time
than a SW vendor. We certainly have precedent for implementing bits of
the ISA via M-mode traps, and that generally comes with a performance
penalty. Whether that performance penalty is tolerable really comes
down to the vendor's target workloads, I don't see any reason V would be
different than everything else.

As far as Linux is concerned the M-mode traps are transparent (ignoring
M-mode Linux, but that's kind of special), though if something's really
slow enough that userspace cares we may end up with a hwprobe
performance bit allocated.

> Honestly.. "V on by default" sounds quite scary.. could you say a bit more
> detail of the exact mechanics that will avoid both breaking and avoid
> significant slowdown on silicon without V?

The mechanisms are broadly the same as what we do for F/D, that's
orthogonal the on/off by default question.