Questions about concurrent & interrupted UMONITOR/UMWAIT behaviors

250 views Asked by At

UMONITOR & UMWAIT instruction for supported Intel x86 processors can be very useful waiting for short period of time in userspace without kernel transition overhead while waiting for shared memory or MMIO variables.

However, some of the description in the instruction manuals are not clear to me and they are mostly about their behavior in concurrency, multiprocessor, and timer/IPI interrupts.

(all of the below questions expect Linux-based environment)

  1. The UMONITOR instruction manual states:

    UMONITOR does not interoperate with the legacy MWAIT instruction. If UMONITOR was executed prior to executing MWAIT and following the most recent execution of the legacy MONITOR instruction, MWAIT will not enter an optimized state. Execution will continue to the instruction following MWAIT.

    The above can be interpreted that any MONITOR, or MWAIT not in execution will be invalid if UMONITOR intervenes between MONITOR and the subsequent MWAIT.

    Also, the UMWAIT instruction manual states:

    A store to the address range armed by the UMONITOR instruction will cause the processor to exit UMWAIT if either the store was originated by other processor agents or the store was originated by a non-processor agent.

    Will each UMONITOR executed in concurrent user threads running be independent from each other for (1) if they are not scheduled to same processor core, or (2) NUMA node? Or is it always valid for 3) any cases, i.e. if there is not subsequent UMONITOR (& MONITOR described below) executed in the same user thread, it will be valid?

  2. The UMWAIT instruction manual states:

    ... The UMWAIT instruction will not wait (will not enter an implementation-dependent optimized state) if any of the following instructions were executed before UMWAIT and after the most recent execution of UMONITOR: IRET, MONITOR, SYSEXIT, SYSRET, and far RET (the last if it is changing CPL).

    The following additional events cause the processor to exit the implementation-dependent optimized state: a store to the address range armed by the UMONITOR instruction, an NMI or SMI, a debug exception, a machine check exception, the BINIT# signal, the INIT# signal, and the RESET# signal. Other implementation-dependent events may also cause the processor to exit the implementation-dependent optimized state.

    In addition, an external interrupt causes the processor to exit the implementation-dependent optimized state regardless of whether maskable-interrupts are inhibited (EFLAGS.IF =0).

    Following exit from the implementation-dependent-optimized state, control passes to the instruction after the UMWAIT instruction. A pending interrupt that is not masked (including an NMI or an SMI) may be delivered before execution of that instruction.

    Unlike the HLT instruction, the UMWAIT instruction does not restart at the UMWAIT instruction following the handling of an SMI.

    If the preceding UMONITOR instruction did not successfully arm an address range or if UMONITOR was not executed prior to executing UMWAIT and following the most recent execution of the legacy MONITOR instruction (UMWAIT does not interoperate with MONITOR), then the processor will not enter an optimized state. Execution will continue to the instruction following UMWAIT.

    1. If 1-(1) does not matter, and since the timer interrupt for scheduler is not the one of interrupt types described above, will the context switching by timer interrupt, other IPI disarm the previous UMONITOR execution for that user thread evicted? Or, will the monitoring-related MSRs be restored to continue? If the later is true, would the rearming miss any previous updates during the disarmed period for subsequent UMWAIT (already executed or not yet)?

    2. Will UMWAIT be interrupted (i.e.resume to execute next instruction) if the bus monitoring set by previous UMONITOR gets disabled, or until OS/user TSC timeout kicks in?

  3. Does UMWAIT still act as hint for busy loop condition like PAUSE, even if the monitor arming fails?

  4. Are multiple UMWAITs without subsequent UMONITOR executed still valid, if they are targetting the same address and the monitoring has not been disabled for any reason? Or, does UMWAIT only disarm the address snooping when the previous store on that address got caught during its execution time?

0

There are 0 answers