Topics

"PAUSE hint instruction" extension


Greg Favor
 

Hi all,

Recently the TSC established a lightweight "fast track" architecture extension process that small, straightforward, relatively uncontentious arch extension proposals can utilize (instead of having to spin up a new Task Group, etc.).  I'm the guinea pig to first take Krste's "PAUSE Hint instruction" proposal from last year through this process.

Attached is a one-page draft spec of the proposal (including some non-normative commentary about what it addresses and doesn't try to address).  Also attached is a pdf of an email discussion from last September on the old 'tech' email list about this proposal and about thoughts for further extensions.

Now, to address some of the requirements of the fast track process:

- This arch extension proposal is following the Fast-Track Architecture Extension process (unless you haven't figured that out already :) ).

- This extension adds a single instruction - the PAUSE instruction (encoded as a HINT instruction) - to the ISA that mirrors what other architectures have, i.e.  x86 PAUSE and TPAUSE, and ARMv8 WFE and YIELD.  This instruction serves to reduce the power and/or improve the performance of “spin-wait loops”.

- The proposed extension name is "Zihintpause".

This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.  Since this proposal has already had prior review discussion and feedback (see the pdf), this last go round will be over the next week or two.  Ultimately, after this, there will then be the standard 45 day public review period as part of the official ratification process.

Thanks,
Greg


Ken Dockser
 

I just searched my email and I do not see any replies to this. Has this discussion died off?

 

I agree that there is a lot of value in using hint instructions that save energy. However, I am having a hard time seeing the value of a pause-type instruction that doesn’t have a standard means of signaling the need to un-pause. ARM’s WFI and WFE are pause-type hint instructions that can be used by code portably across implementations specifically because they have a defined release (i.e., an interrupt and an event, respectively). While this PAUSE instruction could be used for deeply embedded applications where the use is implementation specific, the same effect could be achieved by the implementer using the recommended encoding (or any allowed implantation-specific encoding)  as an implementation defined hint that will act in their implementation defined way.

 

I see in the discussion (that was sent in Greg’s original email) where Andy points out that this is a “baby step” towards something like MWAIT. Why not skip the baby step and create a small extension that includes code-portable energy-saving instructions that have the functionality of MWAIT, WFI and WFE?

 

Thanks,

Ken

 

 

From: tech-unprivileged@... <tech-unprivileged@...> On Behalf Of Greg Favor
Sent: Wednesday, September 16, 2020 11:02 AM
To: tech-unprivileged@...
Cc: Greg Favor <gfavor@...>; Krste Asanovic <krste@...>; Andrew Waterman <andrew@...>
Subject: [RISC-V] [tech-unprivileged] "PAUSE hint instruction" extension

 

CAUTION: This email originated from outside of the organization.

Hi all,

 

Recently the TSC established a lightweight "fast track" architecture extension process that small, straightforward, relatively uncontentious arch extension proposals can utilize (instead of having to spin up a new Task Group, etc.).  I'm the guinea pig to first take Krste's "PAUSE Hint instruction" proposal from last year through this process.

 

Attached is a one-page draft spec of the proposal (including some non-normative commentary about what it addresses and doesn't try to address).  Also attached is a pdf of an email discussion from last September on the old 'tech' email list about this proposal and about thoughts for further extensions.

 

Now, to address some of the requirements of the fast track process:

 

- This arch extension proposal is following the Fast-Track Architecture Extension process (unless you haven't figured that out already :) ).

 

- This extension adds a single instruction - the PAUSE instruction (encoded as a HINT instruction) - to the ISA that mirrors what other architectures have, i.e.  x86 PAUSE and TPAUSE, and ARMv8 WFE and YIELD.  This instruction serves to reduce the power and/or improve the performance of “spin-wait loops”.

 

- The proposed extension name is "Zihintpause".

 

This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.  Since this proposal has already had prior review discussion and feedback (see the pdf), this last go round will be over the next week or two.  Ultimately, after this, there will then be the standard 45 day public review period as part of the official ratification process.

 

Thanks,

Greg


Greg Favor
 

On Thu, Oct 15, 2020 at 1:48 PM Ken Dockser <kdockser@...> wrote:

I agree that there is a lot of value in using hint instructions that save energy. However, I am having a hard time seeing the value of a pause-type instruction that doesn’t have a standard means of signaling the need to un-pause. ARM’s WFI and WFE are pause-type hint instructions that can be used by code portably across implementations specifically because they have a defined release (i.e., an interrupt and an event, respectively). While this PAUSE instruction could be used for deeply embedded applications where the use is implementation specific, the same effect could be achieved by the implementer using the recommended encoding (or any allowed implantation-specific encoding)  as an implementation defined hint that will act in their implementation defined way.


This PAUSE instruction is just like the x86 PAUSE instruction and is what most software would use in spin-wait loops (i.e. inside today's Linux kernel as well as in other libraries and apps).  This is also like ARM's YIELD (i.e. our PAUSE is a 2-for-1).  And is sort of like ARM's WFE - EXCEPT that requires other explicit features in the architecture to be able to work properly and not result in being stuck on it until the next interrupt (however far away in time that might be).

Creating the equivalent of ARM's WFE requires a number of additions to the architecture - which I doubt anyone is up for (and I suspect would be hard to justify).  Creating the direct equivalent of x86 PAUSE (that also can serve as an ARM YIELD) is the clean simple thing to do that is the pretty standard instruction that is used across systems from server to embedded.
 

 I see in the discussion (that was sent in Greg’s original email) where Andy points out that this is a “baby step” towards something like MWAIT. Why not skip the baby step and create a small extension that includes code-portable energy-saving instructions that have the functionality of MWAIT, WFI and WFE?


The non-normative text in the draft spec addresses this.  (All these richer instructions will involve substantial and probably contentious debate as to what should be added, or not added, to the architecture.  Btw, RISC-V already has its equivalent of WFI, and personally I would bet against there being enough people that would vote for adding the multiple bits of arch functionality needed to create the equivalent of WFE.  Which leaves MONITOR/MWAIT as probably the meaty and interesting discussion for another extension proposal - which the non-normative text acknowledges)

Greg
 

 

Thanks,

Ken

 

 

From: tech-unprivileged@... <tech-unprivileged@...> On Behalf Of Greg Favor
Sent: Wednesday, September 16, 2020 11:02 AM
To: tech-unprivileged@...
Cc: Greg Favor <gfavor@...>; Krste Asanovic <krste@...>; Andrew Waterman <andrew@...>
Subject: [RISC-V] [tech-unprivileged] "PAUSE hint instruction" extension

 

CAUTION: This email originated from outside of the organization.

Hi all,

 

Recently the TSC established a lightweight "fast track" architecture extension process that small, straightforward, relatively uncontentious arch extension proposals can utilize (instead of having to spin up a new Task Group, etc.).  I'm the guinea pig to first take Krste's "PAUSE Hint instruction" proposal from last year through this process.

 

Attached is a one-page draft spec of the proposal (including some non-normative commentary about what it addresses and doesn't try to address).  Also attached is a pdf of an email discussion from last September on the old 'tech' email list about this proposal and about thoughts for further extensions.

 

Now, to address some of the requirements of the fast track process:

 

- This arch extension proposal is following the Fast-Track Architecture Extension process (unless you haven't figured that out already :) ).

 

- This extension adds a single instruction - the PAUSE instruction (encoded as a HINT instruction) - to the ISA that mirrors what other architectures have, i.e.  x86 PAUSE and TPAUSE, and ARMv8 WFE and YIELD.  This instruction serves to reduce the power and/or improve the performance of “spin-wait loops”.

 

- The proposed extension name is "Zihintpause".

 

This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.  Since this proposal has already had prior review discussion and feedback (see the pdf), this last go round will be over the next week or two.  Ultimately, after this, there will then be the standard 45 day public review period as part of the official ratification process.

 

Thanks,

Greg


andrew@...
 



On Thu, Oct 15, 2020 at 2:55 PM Greg Favor <gfavor@...> wrote:
On Thu, Oct 15, 2020 at 1:48 PM Ken Dockser <kdockser@...> wrote:

I agree that there is a lot of value in using hint instructions that save energy. However, I am having a hard time seeing the value of a pause-type instruction that doesn’t have a standard means of signaling the need to un-pause. ARM’s WFI and WFE are pause-type hint instructions that can be used by code portably across implementations specifically because they have a defined release (i.e., an interrupt and an event, respectively). While this PAUSE instruction could be used for deeply embedded applications where the use is implementation specific, the same effect could be achieved by the implementer using the recommended encoding (or any allowed implantation-specific encoding)  as an implementation defined hint that will act in their implementation defined way.


This PAUSE instruction is just like the x86 PAUSE instruction and is what most software would use in spin-wait loops (i.e. inside today's Linux kernel as well as in other libraries and apps).  This is also like ARM's YIELD (i.e. our PAUSE is a 2-for-1).  And is sort of like ARM's WFE - EXCEPT that requires other explicit features in the architecture to be able to work properly and not result in being stuck on it until the next interrupt (however far away in time that might be).

Creating the equivalent of ARM's WFE requires a number of additions to the architecture - which I doubt anyone is up for (and I suspect would be hard to justify).  Creating the direct equivalent of x86 PAUSE (that also can serve as an ARM YIELD) is the clean simple thing to do that is the pretty standard instruction that is used across systems from server to embedded.
 

 I see in the discussion (that was sent in Greg’s original email) where Andy points out that this is a “baby step” towards something like MWAIT. Why not skip the baby step and create a small extension that includes code-portable energy-saving instructions that have the functionality of MWAIT, WFI and WFE?


The non-normative text in the draft spec addresses this.  (All these richer instructions will involve substantial and probably contentious debate as to what should be added, or not added, to the architecture.  Btw, RISC-V already has its equivalent of WFI, and personally I would bet against there being enough people that would vote for adding the multiple bits of arch functionality needed to create the equivalent of WFE.  Which leaves MONITOR/MWAIT as probably the meaty and interesting discussion for another extension proposal - which the non-normative text acknowledges)

I'm not entirely in agreement with the remark that PAUSE is a baby-step on the way towards MONITOR/MWAIT.  Although MONITOR/MWAIT do serve some purposes more effectively, there are also common circumstances in which PAUSE is the more effective primitive: namely, when software is waiting on non-memory events or multiple events, or when software isn't aware of precisely which event it is waiting on (as is the case for the cpu_relax() API call in the Linux kernel).  And, anywhere where MONITOR/MWAIT would work well, PAUSE is at least somewhat beneficial.


Greg
 

 

Thanks,

Ken

 

 

From: tech-unprivileged@... <tech-unprivileged@...> On Behalf Of Greg Favor
Sent: Wednesday, September 16, 2020 11:02 AM
To: tech-unprivileged@...
Cc: Greg Favor <gfavor@...>; Krste Asanovic <krste@...>; Andrew Waterman <andrew@...>
Subject: [RISC-V] [tech-unprivileged] "PAUSE hint instruction" extension

 

CAUTION: This email originated from outside of the organization.

Hi all,

 

Recently the TSC established a lightweight "fast track" architecture extension process that small, straightforward, relatively uncontentious arch extension proposals can utilize (instead of having to spin up a new Task Group, etc.).  I'm the guinea pig to first take Krste's "PAUSE Hint instruction" proposal from last year through this process.

 

Attached is a one-page draft spec of the proposal (including some non-normative commentary about what it addresses and doesn't try to address).  Also attached is a pdf of an email discussion from last September on the old 'tech' email list about this proposal and about thoughts for further extensions.

 

Now, to address some of the requirements of the fast track process:

 

- This arch extension proposal is following the Fast-Track Architecture Extension process (unless you haven't figured that out already :) ).

 

- This extension adds a single instruction - the PAUSE instruction (encoded as a HINT instruction) - to the ISA that mirrors what other architectures have, i.e.  x86 PAUSE and TPAUSE, and ARMv8 WFE and YIELD.  This instruction serves to reduce the power and/or improve the performance of “spin-wait loops”.

 

- The proposed extension name is "Zihintpause".

 

This posting to this email list starts an initial review period for people to provide feedback, questions, comments, etc.  Since this proposal has already had prior review discussion and feedback (see the pdf), this last go round will be over the next week or two.  Ultimately, after this, there will then be the standard 45 day public review period as part of the official ratification process.

 

Thanks,

Greg