Topics

PAUSE for LR/SC


Sanjay Patel
 

Hi Folks,

We have defined a custom instruction equivalent to MIPS PAUSE which deschedules the instruction stream when an LL(==RISC-V LR) fails to acquire the lock. If a snoop is detected against the LR address then execution continues beyond the PAUSE and an attempt is made to acquire the lock again. 

This instruction will be named PAUSE.LR and will be a custom instruction in our case unless we can leverage the definition of RISC-V PAUSE. The RISC-V PAUSE as defined (and is in review) suggests that it be used for non-memory events. There is a subsequent suggestion that an rs1 field be used so perhaps rs1=R0 could be used to specify a PAUSE.LR like operation.

There isn't much activity on this
https://lists.riscv.org/g/tech-unprivileged/message/3?p=,,,20,0,0,0::relevance,,PAUSE,20,2,0,76890707
nor the 45-day review
https://lists.riscv.org/g/tech-compliance/message/287?p=,,,20,0,0,0::relevance,,PAUSE,20,2,0,78569228

so I've created a new topic.

Your feedback is welcome with the hope that we can avoid a custom PAUSE.LR.

Sanjay


Greg Favor
 

Sanjay,

This instruction sounds like a more specialized form of the x86 MONITOR/MWAIT instructions?  From a RISC-V architecture standardization perspective, good candidates for standardization have broader (although not necessarily universal) applicability.  In that sense, wouldn't something akin to MONITOR/MWAIT be a suitable RV extension (that would also cover the specific use case you have)?  Or in what way are these two different animals?

Greg


On Tue, Jan 5, 2021 at 3:04 PM Sanjay Patel <spatel@...> wrote:
Hi Folks,

We have defined a custom instruction equivalent to MIPS PAUSE which deschedules the instruction stream when an LL(==RISC-V LR) fails to acquire the lock. If a snoop is detected against the LR address then execution continues beyond the PAUSE and an attempt is made to acquire the lock again. 

This instruction will be named PAUSE.LR and will be a custom instruction in our case unless we can leverage the definition of RISC-V PAUSE. The RISC-V PAUSE as defined (and is in review) suggests that it be used for non-memory events. There is a subsequent suggestion that an rs1 field be used so perhaps rs1=R0 could be used to specify a PAUSE.LR like operation.

There isn't much activity on this
https://lists.riscv.org/g/tech-unprivileged/message/3?p=,,,20,0,0,0::relevance,,PAUSE,20,2,0,76890707
nor the 45-day review
https://lists.riscv.org/g/tech-compliance/message/287?p=,,,20,0,0,0::relevance,,PAUSE,20,2,0,78569228

so I've created a new topic.

Your feedback is welcome with the hope that we can avoid a custom PAUSE.LR.

Sanjay


Allen Baum
 

Monitor-mwait pauses until it "loses" a lock (owns the cachelline), then continues. Any number of external events besides losing a lock may cause it to continue.
If it continues, it must explicitly check if it woke up because of loss of lock, or some other reason (e.g. interrupt, timer, etc).

Pause may deschedule ("temporarily relinquish execution resources to other harts"), but there is no defined event that causes the pause to end (besides a timer expiration).
The intent is to use pause before explicitly checking for some external event, but not to be affected by it.
It is completely undefined whether some event other than timer expiration will cause pause to end - so probably legal.

What you are describing sounds like neither, but your wording is confusing.
LR never "fails". An LR/SC sequence might - in that case, the failure would be if the SC failed to store because someone else touched the reservation address.
For that to be determined, you need to execute the SC, which means the pause must end when the reservation is lost
So your pause.LR is a bit like pause, but 
 - is not bounded (not legal), 
 - you are defining an event that causes pause to end (implementation specific, but probably legal), and
 - is intended to be executed inside a LR/SC sequence, (which the pause spec says you shouldn't do, but I'm not sure that is relevant for the use case, and probably legal).

If pause.LR is  bounded then there must be an explicit check to see if the reservation has been lost.
I think that requires executing the SC to see if it failed, at which point the reservation is reset, and the code needs to loop back to the LR/Pause.LLR sequence to reestablish it.
(because LR/SCs must to come in pairs?).
That sounds like a legal implementation of Pause given its use case, and assuming that it is permissible for an implementation to wake up if an LR reservation is lost
OF course, that makes it fairly useless (but legal) for its intended application, outside of  an LR/SC sequences, where the pause duration would always be zero


 

On Tue, Jan 5, 2021 at 3:25 PM Greg Favor <gfavor@...> wrote:
Sanjay,

This instruction sounds like a more specialized form of the x86 MONITOR/MWAIT instructions?  From a RISC-V architecture standardization perspective, good candidates for standardization have broader (although not necessarily universal) applicability.  In that sense, wouldn't something akin to MONITOR/MWAIT be a suitable RV extension (that would also cover the specific use case you have)?  Or in what way are these two different animals?

Greg


On Tue, Jan 5, 2021 at 3:04 PM Sanjay Patel <spatel@...> wrote:
Hi Folks,

We have defined a custom instruction equivalent to MIPS PAUSE which deschedules the instruction stream when an LL(==RISC-V LR) fails to acquire the lock. If a snoop is detected against the LR address then execution continues beyond the PAUSE and an attempt is made to acquire the lock again. 

This instruction will be named PAUSE.LR and will be a custom instruction in our case unless we can leverage the definition of RISC-V PAUSE. The RISC-V PAUSE as defined (and is in review) suggests that it be used for non-memory events. There is a subsequent suggestion that an rs1 field be used so perhaps rs1=R0 could be used to specify a PAUSE.LR like operation.

There isn't much activity on this
https://lists.riscv.org/g/tech-unprivileged/message/3?p=,,,20,0,0,0::relevance,,PAUSE,20,2,0,76890707
nor the 45-day review
https://lists.riscv.org/g/tech-compliance/message/287?p=,,,20,0,0,0::relevance,,PAUSE,20,2,0,78569228

so I've created a new topic.

Your feedback is welcome with the hope that we can avoid a custom PAUSE.LR.

Sanjay