Re: [BUG] Why does mwait_idle_with_hints() call MWAIT withinterrupts disabled ?

[Mike Galbraith]

On Sat, 2011-07-09 at 06:00 +0530, Linux Smiths wrote:
> Venkatesh,
>                  I see that you have introduced __sti_mwait(), so
> maybe you can explain why we use __mwait() in mwait_idle_with_hints()
> and __sti_mwait() in mwait_idle().
> 
> I know that even before your patch, mwait_idle_with_hints() used to
> behave differently from mwait_idle(), in that it did not use to enable
> interrupt before entering MWAIT sleep, but I'm hoping you can answer
> this question for me.

I got curious enough to blow an inch of virtual dust off the manual..

Software_Delelopers_Manual_Volume:2A:Instruction_Set_Reference:A-M

MWAIT for Address Range Monitoring

For address-range monitoring, the MWAIT instruction operates with the MONITOR
instruction. The two instructions allow the definition of an address at which to wait
(MONITOR) and a implementation-dependent-optimized operation to commence at
the wait address (MWAIT). The execution of MWAIT is a hint to the processor that it
can enter an implementation-dependent-optimized state while waiting for an event
or a store operation to the address range armed by MONITOR.
ECX specifies optional extensions for the MWAIT instruction. EAX may contain hints
such as the preferred optimized state the processor should enter.
For Pentium 4 processors (CPUID signature family 15 and model 3), non-zero values
for EAX and ECX are reserved. Later processors defined ECX=1 as a valid extension
(see below).

A store to the address range armed by the MONITOR instruction, an interrupt, an NMI
or SMI, a debug exception, a machine check exception, the BINIT# signal, the INIT#
signal, or the RESET# signal will exit the implementation-dependent-optimized
state. An interrupt will cause the processor to exit only if the state was entered with
interrupts enabled or if ECX=1.
                   ^^^^^^^^^^^

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/