Linux 5.15-Rc5 x86 Changes Aim to Fix “Yet Another Hardware Trainwreck”
1–5 of 5 posts
Re: Linux 5.15-Rc5 x86 Changes Aim to Fix “Yet Another Hardware Trainwreck”
#2You’d think that it wouldn’t be that hard given that intel can reliably make chips clock at gigahertz without missing a beat
Re: Linux 5.15-Rc5 x86 Changes Aim to Fix “Yet Another Hardware Trainwreck”
#3You’d think that it wouldn’t be that hard given that intel can reliably make chips clock at gigahertz without missing a beat
It's a tradeoff between power consumption and the needs of software. Software needs a high resolution time source that reliably ticks along at a constant rate. From a hardware perspective, there is a strong desire to turn off PLLs to save power when the clocks they generate are "not needed". Unforunately, hardware and software have different definitions of when "not needed" is. Hardware also wants to be able to change the clock speed for clock domains (like a given core's clock rate), but hardware doesn't have any interfaces to tell software exactly when these clock rate changes occur, so software has no way to compensate for the discontinuities in clock rate. Ouch.
The Linux kernel community brought up these requirements with the large CPU vendors at Kernel Summits dating back to the early '00s. To say that the kernel community is frustrated at the state of time keeping in mainstream CPUs is understating it. Software (especially the kernel) is under constant pressure to provide accurate, high resolution and reliable timestamps. That requirement will never go away, so the hardware folks need to figure out how to make an interface that works in the presence of aggressive power savings in modern CPUs. Honestly, if the CPU had a get_time instruction that returned seconds and nanoseconds that was as fast as the TSC, software would use it in an instant (although I'm certain that some hardware vendors would manage to screw it up with BIOS bugs on random motherboards).
Re: Linux 5.15-Rc5 x86 Changes Aim to Fix “Yet Another Hardware Trainwreck”
#4You’d think that it wouldn’t be that hard given that intel can reliably make chips clock at gigahertz without missing a beat
It's a tradeoff between power consumption and the needs of software. Software needs a high resolution time source that reliably ticks along at a constant rate. From a hardware perspective, there is a strong desire to turn off PLLs to save power when the clocks they generate are "not needed". Unforunately, hardware and software have different definitions of when "not needed" is. Hardware also wants to be able to chang…
This may be a naive question: is using a NIC with PTP (nee IEEE-1588) an option for a time source?
Or am I thinking of two completely diverse time source paths, at utterly different HW stacks?
Re: Linux 5.15-Rc5 x86 Changes Aim to Fix “Yet Another Hardware Trainwreck”
#5Earlier quoted context omitted.
It's a tradeoff between power consumption and the needs of software. Software needs a high resolution time source that reliably ticks along at a constant rate. From a hardware perspective, there is a strong desire to turn off PLLs to save power when the clocks they generate are "not needed". Unforunately, hardware and software have different definitions of when "not needed" is. Hardware also wants to be able to chang…
This may be a naive question: is using a NIC with PTP (nee IEEE-1588) an option for a time source? Or am I thinking of two completely diverse time source paths, at utterly different HW stacks?
As soon as you're talking about going outside of the CPU core you're in the territory of slow, and going off chip over PCIe is very slow (hundreds of nanoseconds). That's why many apps continue to make heavy use of rdtsc with all of its quirks and foibles.