Topics

[EXTERNAL]Re: [RISC-V] [tech-unprivileged] PAUSE for LR/SC


Sanjay Patel
 

Hi Allen, Pls see my comment in green.

 

From: Allen Baum <allen.baum@...>
Date: Tuesday, January 5, 2021 at 11:27 PM
To: "tech-unprivileged@..." <tech-unprivileged@...>, Greg Favor <gfavor@...>
Cc: Sanjay Patel <spatel@...>
Subject: [EXTERNAL]Re: [RISC-V] [tech-unprivileged] PAUSE for LR/SC

 

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).

Monitor/mwait semantics are then more complicated then needed for the case I’ve described.

 

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.

I presume this is RISC-V Pause you are describing. MIPS Pause continues execution when a snoop occurs of the address set by the last LL(or LR) executed. A subsequent branch to an LL attempts to acquire the lock again. Hypothetically the RISC-V Pause can be used in place of MIPS Pause but may (or may not) result in more iterations to check the lock. The MIPS Pause is intentionally limited to being released by a coherent memory snoop to optimize performance.  

 

As Greg says in a subsequent email, MIPS Pause is more akin to Arm WFE, except the even is a snoop.

 

What you are describing sounds like neither, but your wording is confusing.

I will send code with usage of LL,PAUSE,SC to clarify the behavior. Yes, my wording was 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.

Acknowledged. LL or LR do not fail in themselves. They read data from memory and the data is tested by a branch.

For that to be determined, you need to execute the SC, which means the pause must end when the reservation is lost

Acknowledged. All in all MIPS LR/SC and RISC-V LL/SC are the same semantically except MIPS LL has the capability to set a hardware maintained address which is compared to snoop addresses to release a PAUSE.

So your pause.LR is a bit like pause, but 

 - is not bounded (not legal), 

It is bounded by an event which clears the reservation, which is a snoop.

 - you are defining an event that causes pause to end (implementation specific, but probably legal), and

This will work for any coherent memory mechanism.

 - 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).

Yes. Meant specifically for LL/SC spin-locks.

 

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

Could you describe to me how RISC-V PAUSE as described is to be used?  

 

I will send you the code.

 

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