UMWAIT

UMWAIT is the MWAIT that a user program may run. After UMONITOR has armed the address monitor on a location, UMWAIT lets the core rest until a store hits it, an interrupt arrives (even with IF clear) or the time-stamp counter reaches a deadline. Intel’s optimization manual suggests it for threads that poll a descriptor ring or wait for a device’s completion record (Section 3.13.1.3). Unlike MWAIT’s deeper states, a store from a device wakes it as surely as one from another processor.

The deadline is a time, not a delay#

EDX:EAX holds the TSC value at which to stop, so a program adds its timeout to a fresh RDTSC reading. A small number is a moment long past, and the wait ends at once. Intel’s own optimization manual gets this wrong: Example 3-59 passes 100000 as “some high value in timeout”.

The operating system has the last word. IA32_UMWAIT_CONTROL (MSR E1H) caps any wait at the TSC count in its bits 31:2, and its bit 0 turns requests for the deeper state into the lighter one. UMWAIT sets CF when that cap, not the program’s deadline, ended the wait, and clears OF, SF, ZF, AF and PF. The register operand picks the state: bit 0 = 0 asks for C0.2, which saves more and helps the other hardware thread of the core, bit 0 = 1 for C0.1, which wakes faster; other bits raise #GP. CR4.TSD also makes it raise #GP outside ring 0, as for RDTSC.

When it does not wait#

UMWAIT returns at once if no UMONITOR armed the monitor, if MONITOR ran since, or if an IRET, SYSRET, SYSEXIT or a far RET to another privilege level came between the two, as happens when the thread was interrupted or preempted. The loop therefore checks the location before UMONITOR, between the two instructions and after UMWAIT, as Intel’s optimization manual shows.

From C and on AMD#

_umonitor(p) and _umwait(control, deadline) need -mwaitpkg or an -march that has WAITPKG, such as alderlake or sapphirerapids; neither x86-64-v4 nor znver5 does. GCC 14 and Clang 23 at -O2 return CF with SETC or SETB after UMWAIT. No AMD processor in this site’s data has WAITPKG (CPUID leaf 07H, ECX bit 5), so Zen 5 recorded no cases; AMD’s MWAITX is the nearest equivalent, with a maximum wait in EBX counted from the start.

In the optimization guide

What the optimization guide says about UMWAIT, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Crestmont and Gracemont

• Hybrid processors: Intel advises against pinning threads to cores and for waiting with UMWAIT, TPAUSE or PAUSE. sources differ

Golden Cove and Raptor Cove

• Threads and hybrid parts: On Alder Lake and Raptor Lake, Thread Director tells the operating system how each thread would fare on either kind of core. sources differ
• Threads and hybrid parts: Two AMX threads on one core, or an AMX thread beside another busy thread, slow each other down.

Tremont

• Instruction set and Lakefield: Tremont adds UMWAIT, TPAUSE, CLWB, CLDEMOTE and the direct stores, which GCC enables for it. sources differ

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

c = src.read()                   # bit 0: 1 for C0.1, which wakes
if c & ~1:                       # sooner; 0 for C0.2, which saves
    fault(GP, 0)                 # more, unless the OS forbids it
if CPL > 0 and cr4 >> 2 & 1:     # CR4.TSD, as for RDTSC
    fault(GP, 0)
t = edx << 32 | eax              # rests until the TSC reaches t, a
                                 # store hits the range of UMONITOR or
                                 # an event comes
cf = os_timeout(t)               # 1 when the OS's limit came first
of = sf = zf = af = pf = 0
# without an armed monitor it does not wait

Operands

Flags

Attributes

What else XED records about the forms. How to read.

All forms

may abort a TSX transaction

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More WAITPKG instructions

• TPAUSE
• UMONITOR