Benjamin Herrenschmidt wrote:
> On Sat, 2007-05-19 at 19:43 -0700, Daniel Walker wrote:
>
>> 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 <[email protected]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
