Benjamin Herrenschmidt wrote:
On Sat, 2007-05-19 at 19:43 -0700, Daniel Walker wrote:
quoted
In terms of clocksources, gettimeofday() would have to switch to another
clocksource if the decrementer started to act that way .. That's why it
is possible to register more than one clocksource, to allow for the
switching. The decrementer frequency doesn't change even with cpufreq?
It's more than just gettimeofday. The linux ppc kernel port has strong
assumptions all over the place that the timbase and decrementer (which
always tick at the same rate) have a constant frequency. It might be
possible to "fix" those assumptions but right now, that is the case.
For example, nowadays, udelay() also uses the timebase. Not only
gettimeofday() & friends. The scheduler ticking too. The precise process
accounting as well, etc...
So.. if we get enough clocksources into the tree, can any of those
parts of the code be reworked to use clocksources/clockevents and
hrtimers quickly and easily? I noticed the patch just posted does
some of it.. but not as much as Ben just mentioned.
Or is it a development nightmare?
I'm fairly sure on a PPC970 box even though the decrementer is
monotonic and never changes frequency, one day it just might, and
it would be better to anticipate this (and allow people to
distribute their timing requirements across an entire system
and not just the CPU core anyway, which I think is probably a
good thing from a system integration and possibly the point of
view of redundancy..)
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations