[RVV] - re-entrant VLD/VSD?

61 views
Skip to first unread message

Luke Kenneth Casson Leighton

unread,
Oct 5, 2018, 4:04:10 AM10/5/18
to RISC-V ISA Dev
Vector LOAD/Store has the issue that multiple page faults can occur
which will need handling, however they are on a single instruction,
and without sufficient state information it is not possible to return.
has it been considered or discussed on the RVV WG the possibility of
exposing sufficient state information (the loop index) to handle this
situation in software-only TLB implementations?

l.

Andrew Waterman

unread,
Oct 5, 2018, 5:03:01 AM10/5/18
to Luke Kenneth Casson Leighton, RISC-V ISA Dev
It has been discussed at length, both in the RVV group and over the course of the last several decades' worth of vector-machine design.  It's not written in the V spec document because it's not necessarily germane to the unprivileged software interface.

The prevailing proposal is to have an element-progress CSR that indicates which element caused the exception.  The same CSR also indicates which element at which to start vector execution, so that after the page fault is handled, the older elements don't re-execute.  (Note that the motivation has nothing to do with performance; it's just about maintaining the forward-progress guarantee.)

Completely executing a vector instruction causes the progress CSR to be reset to 0, so that the next vector instruction starts executing at element 0.

This approach is fully compatible with software TLB refill, but keep in mind that building a vector machine with software TLB refill is a terribly obvious pitfall.  The significant overhead of stopping the world to handle a TLB miss exacerbates an Amdahl's-law bottleneck, and the hardware savings is pretty minor.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAPweEDwD%3DXw-%2Bn6_yfKWfz5swpAzpQynMTsdTE34xR5sgufQ7g%40mail.gmail.com.

Luke Kenneth Casson Leighton

unread,
Oct 5, 2018, 5:42:54 AM10/5/18
to Andrew Waterman, RISC-V ISA Dev
On Fri, Oct 5, 2018 at 10:03 AM Andrew Waterman
<wate...@eecs.berkeley.edu> wrote:

> [...]
> The prevailing proposal is to have an element-progress CSR
> that indicates which element caused the exception. The same CSR
> also indicates which element at which to start vector execution,
> so that after the page fault is handled, the older elements don't
> re-execute

makes sense.

thanks for the informative and clear reply, andrew.

l.

Alex Solomatnikov

unread,
Oct 5, 2018, 1:37:57 PM10/5/18
to Andrew Waterman, RISC-V ISA Dev
What about chaining? How do chain operation(s) get restarted? Is there CSR(s) for that?

Also, is possible to 2 page faults simultaneously if store is chained after load? E.g. vld; vadd; vst ?

On Fri, Oct 5, 2018 at 2:02 AM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:
It has been discussed at length, both in the RVV group and over the course of the last several decades' worth of vector-machine design.  It's not written in the V spec document because it's not necessarily germane to the unprivileged software interface.

The prevailing proposal is to have an element-progress CSR that indicates which element caused the exception.  The same CSR also indicates which element at which to start vector execution, so that after the page fault is handled, the older elements don't re-execute.  (Note that the motivation has nothing to do with performance; it's just about maintaining the forward-progress guarantee.)

Completely executing a vector instruction causes the progress CSR to be reset to 0, so that the next vector instruction starts executing at element 0.

This approach is fully compatible with software TLB refill, but keep in mind that building a vector machine with software TLB refill is a terribly obvious pitfall.  The significant overhead of stopping the world to handle a TLB miss exacerbates an Amdahl's-law bottleneck, and the hardware savings is pretty minor.
On Fri, Oct 5, 2018 at 1:04 AM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
Vector LOAD/Store has the issue that multiple page faults can occur
which will need handling, however they are on a single instruction,
and without sufficient state information it is not possible to return.
has it been considered or discussed on the RVV WG the possibility of
exposing sufficient state information (the loop index) to handle this
situation in software-only TLB implementations?

l.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0A9UarGKvyTyhXoc2teOs4sBvjwmV-Scb-V20Ba4EescA%40mail.gmail.com.

Andrew Waterman

unread,
Oct 5, 2018, 3:37:19 PM10/5/18
to Alex Solomatnikov, RISC-V ISA Dev
On Fri, Oct 5, 2018 at 10:37 AM Alex Solomatnikov <so...@sifive.com> wrote:
What about chaining? How do chain operation(s) get restarted? Is there CSR(s) for that?

In systems with virtual memory, the machine must have element-precise exceptions, so any chained operations must appear to have not begun executing. It’s not as bad as it sounds. For unit-stride and short-stride accesses that can touch at most two pages of memory, you only need to check the first and last address, making it possible to prove the instruction will commit before the next instruction begins chaining. For longer strides and scatter/gather, you can just stall the next instruction.

In some other systems, particularly embedded ones where access exceptions are not expected to be resumable, it’s kind of a moot point: the chained operations might destroy some state, and and so be it. For debugging purposes, you could provide a slow mode that disables chaining so that exceptions are precise. (Or perhaps the slow mode should be defined to be the default, but in practice you’ll always engage the fast mode.)


Also, is possible to 2 page faults simultaneously if store is chained after load? E.g. vld; vadd; vst ?

On Fri, Oct 5, 2018 at 2:02 AM, Andrew Waterman <wate...@eecs.berkeley.edu> wrote:
It has been discussed at length, both in the RVV group and over the course of the last several decades' worth of vector-machine design.  It's not written in the V spec document because it's not necessarily germane to the unprivileged software interface.

The prevailing proposal is to have an element-progress CSR that indicates which element caused the exception.  The same CSR also indicates which element at which to start vector execution, so that after the page fault is handled, the older elements don't re-execute.  (Note that the motivation has nothing to do with performance; it's just about maintaining the forward-progress guarantee.)

Completely executing a vector instruction causes the progress CSR to be reset to 0, so that the next vector instruction starts executing at element 0.

This approach is fully compatible with software TLB refill, but keep in mind that building a vector machine with software TLB refill is a terribly obvious pitfall.  The significant overhead of stopping the world to handle a TLB miss exacerbates an Amdahl's-law bottleneck, and the hardware savings is pretty minor.
On Fri, Oct 5, 2018 at 1:04 AM Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
Vector LOAD/Store has the issue that multiple page faults can occur
which will need handling, however they are on a single instruction,
and without sufficient state information it is not possible to return.
has it been considered or discussed on the RVV WG the possibility of
exposing sufficient state information (the loop index) to handle this
situation in software-only TLB implementations?

l.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
Reply all
Reply to author
Forward
0 new messages