Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

[Andi Kleen <andi@firstfloor.org>]

Eduard-Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
>
> Other kernel developers, as discussed previously in this thread, are
> working on a HPET-driven dynticks (as opposed to the current
> LAPIC-driven one), but the change isn't that easy to make.

No, actually HPET based dyntick has been implemented for a long time
(as long as APIC based dyntick). APIC based dyntick is preferred 
because it is a little cheaper, but both are there.

The problem is just that many BIOSes don't tell the kernel about the
HPET location (even when the chipset supports it) because that wasn't
needed for older Windows versions.  And without the BIOS telling the
kernel HPET it doesn't know where it is and can't use it when
the APIC timer is not usable.

The ongoing work is to implement hpet=force code that knows
about various chipsets and reads their hardware registers directly
and then uses the HPET timer without BIOS support.

The reason it is still an option is that there used to be at least one
old chipset where forcing the HPET could trigger hardware bugs.

On the other hand it is expected that BIOS versions support Vista
also supply HPET, so that problem will hopefully get better.

> This way,
> dynticks and C1E could be both enabled and thus save more power.

I would not expect too much over a HZ=100 kernel on current AMD. 

C1e doesn't have too much latency on its own. iirc at least on current
AMD platforms sleeping for longer didn't make too much
difference. With HZ=250 it might be borderline, but I would not expect
miracles. It's probably only clearly a good idea if you're on a
HZ=1000 kernel or have applications that need very precise hrtimers (but that
might cost more power again because it'll cause more wakeups) 

Of course this can always change in future systems -- these are
just rules of thumb currently.

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