Thank you for your time, and sorry about the confusion
that I might have caused with Xen scheduler and cpuidle.
I've misunderstood them completely.
On 10/13/2011 08:42 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 07, 2011 at 10:31:37PM +0300, Marko Ristola wrote:
>> for this old hardware. Only problem with the hardware is, that
>> XEN Hypervisor scheduler doesn't use HPET. I think hypervisor scheduler
>> does busy looping, instead of using HALT instruction.
> The default operation is to use 'hlt' (from arch/x86/domain.c in
> Xen 4.1.1 hypervisor):
> static void default_idle(void)
> if ( cpu_is_haltable(smp_processor_id()) )
> HPET does not have anything to do with HALT. HPET is used to
> figure out the time.
Oops. I'm very sorry.
I have following lines:
"(XEN) Platform timer is 3.579MHz ACPI PM Timer".
"(XEN) CPUIDLE: disabled due to no HPET. Force enable with 'cpuidle'."
I have no problem with these now, so let's go on.
>> "hpet=force" was on XEN Hypervisor a few years ago, but the code has been
>> I don't know if it is coming back.
> Unless somebody posts a patch - then no.
Is it okay to grab the code bits from Linux kernel and create a patch?
I need equal semantics from the Kernel, to be able to verify that the patch
>> I can test old hardware so that XEN hypervisor and DOM0 messages go into a
>> serial cable.
> That is appreciated. The Xen ACPI cpufreq patches that would push up the _P
> states to
> the hypervisor are not yet ready - but when they are ready it would be very
> good to try
> it out on your hardware.
> Note, the ACPI cpufreq patches enable the hypervisor to use different
> methods that just doing 'hlt'. They can use 'mwait' or some other form
> of putting the CPU to sleep.. and naturally also change the frequency and
> fancy things.
Sounds very good: power saving features will just work.
xen mailing list