Opened 6 years ago

Last modified 16 months 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
Has a Patch: no 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 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

Change History (17)

comment:1 Changed 6 years ago by axeld

  • Description modified (diff)

comment:2 Changed 6 years ago by axeld

  • Description modified (diff)

comment:3 Changed 6 years ago by stippi

  • Description modified (diff)

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by 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.

comment:6 Changed 6 years ago by dustin howett

  • Component changed from - General to System/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 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by leavengood

  • 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 Changed 5 years ago by 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.

comment:10 follow-up: Changed 5 years ago by 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.

comment:11 Changed 5 years ago by 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.

comment:12 Changed 4 years ago by axeld

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

comment:13 in reply to: ↑ 10 Changed 4 years ago by 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.

comment:14 Changed 4 years ago by jackburton

  • Priority changed from high to normal

comment:15 Changed 4 years ago by 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.

comment:16 Changed 4 years ago by bonefish

  • 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 Changed 16 months ago by bonefish

  • Blocking 9277 added

(In #9277) Duplicate of #1993.

Note: See TracTickets for help on using tickets.