Re: [Xen-devel] please revert c/s 17686

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 13.06.08 09:31 >>>
>On 13/6/08 03:08, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
>
>> Ok. Without hpet_broadcast, C3 can't work now.
>> 
>> First, we need to add check for mechanism readiness before entering C3
>> to avoid sleeping forever as you mentioned.
>> 
>> Second, there are 3 options to reenable C3.
>>   - Use pit_broadcast. Straightforward, may have some impacts on
>> tick-less effect.
>>   - Emulate RTC with legacy HPET. Need back porting from latest Linux
>> kernel.
>>   - Enable FSB delivery for HPET interrupt. Not all models support this
>> mode.
>> 
>> We would like to go with pit_broadcast first to ensure the C3 usability,
>> and look at other options later.
>
>Will you keep the 10ms tick in this case? If that's acceptable it should be
>a simple patch.

I think it would be nice it the tick was enabled only when at least one
CPU actually is about to enter or in C3. And I'm not certain whether
it wouldn't be possible to use a larger value than 10ms - at least in the
case where all CPUs are in C3 (but I see that this case doesn't really
seem to be expected anyway, given the warning handle_hpet_broadcast()
generates when the current CPU is in the channel's mask; I'm also
unclear about how the warning is avoided when the CPU currently in
charge of handling the timer interrupt is to enter C3 - maybe I'm
overlooking a place where the affinity get changed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel