Hi Konrad.
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)
{
local_irq_disable();
if ( cpu_is_haltable(smp_processor_id()) )
safe_halt();
else
local_irq_enable();
}
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 removed.
> 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 works.
>
> 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 those
fancy things.
Sounds very good: power saving features will just work.
Regards,
Marko Ristola