Implement using HPET timers and other mechanisms than TSC for time keeping

[axeld]

On CPUs that are able to change their frequency, the TSC increment is not invariant. Therefore, we cannot use it to compute time on these machines. Unfortunately, most recent CPUs are affected due to power saving features.

Furthermore, in an SMP environment, the TSC of the different CPUs can drift apart. See ​http://lkml.org/lkml/2005/11/4/173 for an interesting insight on that topic.

For HPET (and PM timer) see ACPI 3.0 specification ​http://www.acpi.info/spec.htm and ​http://www.intel.com/technology/architecture/hpetspec.htm

[mmlr]

Just to document that: In fact the same mechanism as in the cpu_fix driver can be used to "resync" the system time after a frequency change. By adjusting the conversion factor and the time base the system_time() can be made reliable without interruption (​http://beos.mlotz.ch/documents/cpu_fix.html). So the only thing that is a problem are unsynchronized TSCs across multiple cores/processors. As far as I know though only certain AMD multi core processors do not provide an invariant TSC across the cores (as described in the lkml message you linked). I mention that since using the CPU internal rdtsc is desirable for performance reasons and therefore should be used when possible.

[axeld]

That's not entirely correct, as this requires you to detect (or trigger) such a frequency change in a timely manner. And even then, there is a certain drift you cannot avoid.

Also HPET is supposed to be a pretty well performing timer, as well. We're currently using APIC and PIT timers for semaphores, and those are less exact and slower to program than HPET is supposed to be.

[dustin howett]

Working on it; commenting on it to add my cc because I can't quite be assigned this ticket. Also, I quite think it's a Kernel thing.

[mmu_man]

On the qemu-devel ml someone ​suggested we have a look at ​KVM_CLOCK from linux, it's not yet useful outside of KVM, but might someday be supported by QEMU.

There is also some TSC data in vmware's vmport.

[leavengood]

What is the status of this work? Should we just leave it to Dustin to finish eventually or should it be another GSoC idea? I think we should leave it up to Dustin...

[anevilyak]

To my knowledge it's on hold because using HPET correctly requires us to be fully using ACPI also (which is to say using it for device enumeration and configuration as well). The latter would be a bit too much for someone to tackle as a summer project unless they have a great deal of knowledge. Someone correct me if I'm wrong.

[dustin howett]

You're quite right. This support is on hold pending proper ACPI interrupt routing. I was looking into it previously, but it proved to be quite more in-depth than I'd first thought.

[leavengood]

OK then I will remove this as an idea for GSoC. But should we add an idea for ACPI support? Or is that too complicated for GSoC? Seems like it is better left for our kernel experts.

[jackburton]

Replying to dustin howett:

You're quite right. This support is on hold pending proper ACPI interrupt routing. I was looking into it previously, but it proved to be quite more in-depth than I'd first thought.

Looks like this isn't completely true. We are able to use HPET in legacy mode without ACPI routing, on machines which supports that. After hrev35611 HPET timers should be usable, at least disabling SMP, although I did not enable them by default.

[jackburton]

HPET support is in there, at least for one-shot timers (used by the scheduler). In the current form, though, the timer infrastructure isn't very flexible, and a timer type can only be used for everything or for nothing; best would be having different timers used for different things, i.e. HPET for timekeeping, LAPIC for one-shot timers, etc. depending on the availability and on the quirks of the hardware IOW we should write a full featured timer abstraction layer.

[bonefish]

(In #6152) Yep, #1993 had been created for that problem, though it's actually not that urgent anymore, since, unlike that ticket description says, current CPUs have a stable TSC.

[bonefish]

(In #9277) Duplicate of #1993.

[kallisti5]

Is this still an issue after the SMP rework last year?

[anevilyak]

As far as I'm aware, nothing about the new scheduler would have changed the problems highlighted by this bug.

[Giova84]

I land here from ticket:6152 (clock runs slow). I am on a Sony Vaio provided with a Celeron M 1,50 Ghz: I notice that the system clock starts to be slow, when I detach the power cable and I let the laptop on battery, which is new (and as I reported elesewhere, there is an huge battery drain).