One-shot-oriented event timers management

[Alexander Motin]

Alexander Motin wrote:
> YAMAMOTO, Taku wrote:
>> On Mon, 30 Aug 2010 13:07:38 +0300
>> Alexander Motin <mav at FreeBSD.org> wrote:
>>> Gary Jennejohn wrote:
>> (snip)
>>>> So, what else did you do to reduce interrupts so much?
>>>>
>>>> Ah, I think I see it now.  My desktop has only C1 enabled.  Is that it?
>>>> Unfortunately, it appears that only C1 is supported :(
>>> Yes, as I have said, at this moment empty ticks skipped only while CPU
>>> is in C2/C3 states. In C1 state there is no way to handle lost events on
>>> wake up. While it may be not very dangerous, it is not very good.
>> There's an alternative way to catch exit-from-C1 atomically:
>> use MWAIT with bit0 of ECX set (``Treat masked interrupts as break events''
>> in Intel 64 and IA-32 Architecthres Software Developer's Manual).
>>
>> In this way we can put each core individually into deeper Cx state without
>> additional costs (SMIs and the like) as a bonus.
>>
>> The problem is that it may be unavailable to earlier CPUs that support
>> MONITOR/MWAIT instructions:
>> we should check the presense of this feature by examining bit0 and bit1 of ECX
>> that is returned by CPUID 5.
> 
> Thank you for the hint. I will investigate it now. But it still help
> only x86 systems. I have no idea how power management works on
> arm/mips/ppc/..., but I assume that periodic wake up there also may be
> not free.

I have looked on these MWAIT features. They indeed allow to wake up with
interrupts disabled, but I am worrying about the C-state in which CPU
goes in that case. MWAIT states are CPU C-STATES, not ACPI C-states. So
I have doubts that using MWAIT instead of HLT on ACPI system is correct.
Also I have found some comments that MWAIT on AMD 10h family CPUs does
not allows CPU to go to C1E state, while HLT does. So it is not a
complete (worse) equivalent. Later AMD CPUs just do not support MWAIT.

-- 
Alexander Motin