FRESH

Hacker News

An Analysis of User-Space Idle State Instructions on x86 Processors

22 points by blakepelton

by blakepelton

1 subcomments

Here is my summary: https://danglingpointers.substack.com/p/an-analysis-of-user-...

by bob1029

0 subcomment

I feel like there are cases where burning an entire core on busy waiting will result in better overall power consumption than if we sleep and yield as much as possible throughout.
Bringing a core back from the dead each time can be a very expensive operation. If you never yield to the operating system, your working set is ~guaranteed to be hot. Communicating information is substantially more expensive than processing information in terms of energy consumption. DRAM and infinity fabric don't work for free. One AMD CCX maxed out is nothing compared to saturating the memory subsystem.

by jeffbee

0 subcomment

I was psyched about UMWAIT and TPAUSE when Alder Lake arrived but unfortunately Intel has never shipped a model where these features actually work right. There have been errata all over the topic of the monitors failing to fire. TPAUSE also unfortunately useless since you have to read TSC, it just takes too long.

by dgacmu

0 subcomment

This is very cool. Uh, no pun intended. For those looking for a tl;dr: recent instruction sets add a "pause in low power for x time" busy wait instruction and a "pause for time + or if this memory is touched" instruction. Particularly on e-cores and epyc rome, these instructions can save a good amount of power vs traditional busy waiting while hitting wakeup time targets quite well. Nifty stuff.