On Fri, Dec 09, 2022 at 11:42:19AM -0800, Vineet Gupta wrote:
But keeping the V unit disabled by default and using prctl as a gatekeeperPlease reference the previous discussion [1] which has covered topics that
to enable it feels unnecessary and tedious.
Here's my reasoning below (I'm collating comments from prior msgs as well).
have not been discussed recently.
[1] https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361
2. People want the prctl gatekeeping for ability to gracefully handle memoryBut vector state scales up to as much as 256k. Are you suggesting that
allocation failure for the extra V-state within kernel. But that is only
additional 4K (for typical 128 wide V regs) per task.
there is no possibility that future systems would support more than
VLEN=128?
If that is failing,This seems unlikely. As vector support does not exist in any present
the system is not doing well anyways. Besides it is not an issue at all
since ENOMEM in clone/execve for the additional space should handle the
failure anyways. Only very sophisticated apps would downgrade from executing
V to Scalar code if the prctl failed.
hardware, and the vector extension is only optional in the RISC-V profiles
that include it, I would think that it is almost certain that any
application that supports V would have a fallback path for when the V
extension is not available.
Another motivation for requiring that user space request use of the vector
extension is that the vector unit may be shared between multiple harts
and/or have power or performance implications in the system. By requiring
that user space request access, it allows the system to decline that
access, and user space can handle this gracefully.
If we add a mechanism for user space to request access to the vector
extension, and it turns out that it was unnecessary, the worst that has
happened is a slight inconvenience.
If we do not add such a mechanism, and later determine that it is
necessary, we have a much greater problem. There would be backward
compatibility issues with the ABI, and such a mechanism could probably not
be fully implemented at all due to the desire to support potential future
legacy vector code.
This is a similar problem on x86. According to some, it was handled poorly
with AVX-512 by missing this type of mechanism, and improved with AMX [2].
There is opportunity to learn from that experience and do things better on
RISC-V.
[2] https://lore.kernel.org/lkml/87k0ntazyn.ffs@xxxxxxxxxxxxxxxxxxxxxxx/