MWAIT vs HALT in terms of efficiency

Question

I'm raising a wonder in regards to MONITOR-MWAIT vs HLT instructions. Both halts the processor, both wakes up on various external triggers (interrupts etc).

In my experiments, HLT and MWAIT function almost the same, when taking in account :

• If you are not the OS scheduler, a simple loop with the above mentioned instructions, will be interrupted quite rapidly, and since MWAIT requires re-checking the condition in between MONITOR and MWAIT, what is the difference ? (what i'm asking is, why not using HLT in first place, and saving the pain of allocating tracing area (which, if not carefully configured, avoids the mon/mwait mechanism and turns it into a NOP), since if you're not the OS scheduler, there is no chance you won't wake up rapidly enough to simply check the value in a HLT loop... ???

(surely, MWAIT could be higher res, i haven't measured resolution, but it seems it over-wake-ups by (i assume) interrupts and such).. so i can't see the big advantage.

Thanks, Any thoughts in that manner would be greatly appreciated

Answer 1

For performance; what matters most is the time it takes for the CPU to come out of its "waiting" state whenever whatever it is waiting for (an IRQ for HLT, or either an IRQ or a memory write for MWAIT) occurs. This effects latency - e.g. how long it will take before an interrupt handler is started or before a task switch actually occurs. The time taken for a CPU to come out of its waiting state is different for different CPUs, and may also be slightly different for HLT and MWAIT on the same CPU.

The same applies to power consumption - power consumed while waiting can vary a lot between different CPUs (especially when you start thinking about things like hyper-threading); and power consumption of HLT vs. MWAIT may also be slightly different on the same CPU.

For usage, they're intended for different situations. HLT is for waiting for an IRQ, while MWAIT is for waiting for a memory write to occur. Of course if you're waiting for a memory write to occur then you need to decide whether IRQs should interrupt your waiting or not (e.g. you can do CLI then MWAIT if you only want to wait for a memory write).

However, for multi-tasking systems, mostly they're both only used for the same thing - in schedulers where the CPU is idle. Before MONITOR/MWAIT was introduced, schedulers would use HLT while waiting for work to do (to reduce power consumption a little). This means that if another CPU unblocks a task it can't just put that task into the scheduler's queue and has to send a (relatively expensive) "inter-processor interrupt" to the HLTed CPU to knock it out of its HLT state (otherwise the CPU will keep doing nothing when there's work it can/should do). With MWAIT, this "inter-processor interrupt" is (potentially) unnecessary - you can set MONITOR to watch for writes to the scheduler's queue, so that the act of putting the task onto the queue is enough to cause a waiting CPU to stop waiting.

There has also been some research into using MONITOR/MWAIT for things like spinlocks and synchronisation (e.g. waiting for a contended lock to be released). The end result of this research is that the time it takes for the CPU to come out of its "waiting" state is too high and using MONITOR/MWAIT like this causes too much performance loss (unless there are design flaws - e.g. using a spinlock when you should be using a mutex).

I can't think of any other reason (beyond schedulers and locking/synchronisation) to use HLT or MWAIT.

Answer 2

MONITOR/MWAIT should be usable "for things like spinlocks and synchronisation (e.g. waiting for a contended lock to be released)."

However, MONITOR/MWAIT (a) for an amazingly stupid and annoying reason had to be restricted to only be used by ring 0 kernel code, not user code, and (b) became loaded down with microcode to go into low power sleep states.

Some companies have implemented similar or equivalent instructions better, e.g.MIPS' LL/PAUSE is roughly equivalent to MONITOR/MWAIT.