Opened 12 years ago

Last modified 3 years ago

#1993 new enhancement

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

Reported by: axeld Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version:
Keywords: Cc: leavengood@…
Blocked By: Blocking: #6152, #9277
Platform: All

Description (last modified by stippi)

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 for an interesting insight on that topic.

For HPET (and PM timer) see ACPI 3.0 specification and

Change History (20)

comment:1 by axeld, 12 years ago

Description: modified (diff)

comment:2 by axeld, 12 years ago

Description: modified (diff)

comment:3 by stippi, 12 years ago

Description: modified (diff)

comment:4 by mmlr, 12 years ago

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 ( 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.

comment:5 by axeld, 12 years ago

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.

comment:6 by dustin howett, 12 years ago

Component: - GeneralSystem/Kernel

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.

comment:7 by mmu_man, 11 years ago

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.

comment:8 by leavengood, 11 years ago

Cc: leavengood@… added

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...

comment:9 by anevilyak, 11 years ago

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.

comment:10 by dustin howett, 11 years ago

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.

comment:11 by leavengood, 11 years ago

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.

comment:12 by axeld, 11 years ago

Owner: changed from axeld to nobody
Version: R1/pre-alpha1

in reply to:  10 comment:13 by jackburton, 10 years ago

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.

comment:14 by jackburton, 10 years ago

Priority: highnormal

comment:15 by jackburton, 10 years ago

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.

comment:16 by bonefish, 10 years ago

Blocking: 6152 added

(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.

comment:17 by bonefish, 8 years ago

Blocking: 9277 added

(In #9277) Duplicate of #1993.

comment:18 by kallisti5, 4 years ago

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

comment:19 by anevilyak, 4 years ago

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

comment:20 by Giova84, 3 years ago

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).

Note: See TracTickets for help on using tickets.