Christoph Lameter wrote:
On Fri, 26 Aug 2005, Alex Williamson wrote:
Would we ever want to favor a frequency shifting timer over anything
else in the system? If it was noticeable perhaps we'd just need a
callback to re-evaluate the frequency and rescan for the best timer. If
it happens without notice, a flag that statically assigns it the lowest
priority will due. Or maybe if the driver factored the frequency
shifting into the drift it would make the timer undesirable without
resorting to flags. Thanks,
Timers are usually constant. AFAIK Frequency shifts only occur through
power management. In that case we usually have some notifiers running
before the change. These notifiers need to switch to a different time
source if the timer frequency will be shifting or the timer will become
unavailable.
If there is a notifier, I presume we can track it. We might want to
refine things so as to not hit too big a bump when the shift occures,
but I think it is doable. The desirability of doing it, I think,
depends on the availablity of something better. The access time of the
TSC is "really" enticing. Even so, I think a _good_ clock would not
depend on long term accuracy of something as fast as the TSC. Vendors
are even modulating these to reduce RFI, but still, because of its
speed, it makes the best interpolator for the jiffie to jiffie times.
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |