Messages in this thread | | | Subject | Re: [PATCH] Option to disable AMD C1E (allows dynticks to work) | From | Andi Kleen <> | Date | Sun, 30 Dec 2007 15:42:17 +0100 |
| |
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
| |