[lkml]   [2005]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Need better is_better_time_interpolator() algorithm
On Thu, 25 Aug 2005, Alex Williamson wrote:

> I don't know that it's that uncommon. Simply having one non-arch
> specific timer is enough to need to decided whether it's better than a
> generic timer. I assume pretty much every arch has a cycle timer. For
> smaller boxes, this might be the preferred timer given it's latency even
> if something like an hpet exists (mmio access are expensive). How do
> you hard code a value that can account for that? I agree, we could
> easily go too far and produce some bloated algorithm, but maybe it's
> simply a weighted product of a few variables.

I think a priority is something useful for the interpolators. Some of
the decisions about which time sources to use also have criteria different
from drift/latency/jitter/cpu. F.e. timers may not survive various
power-saving configurations. Thus I would think that we need a priority
plus some flags.

Some of the criteria for choosing a time source may be:

1. If a system boots up with a single cpu then there is no question that
the ITC/TSC should be used because of the fast access.

2. If the BIOS is capable of perfect ITC/TSC synchronization then use
the ITC/TSC. However, this is typically restricted to SMP configs and
there is an issue on IA64 that the PAL can indicate a nodrift
configuration but Linux is not capable of perfects sync on bootup.

3. If a memory mapped global clock is available then make sure to
first use a distributed timer over a centralized time source because
distributed timer have fast local access even under contention.
I.e. use Altix RTC over HPET/Cyclone.

4. Use any memory mapped global clock source

5. Abuse some other system component for time keeping (PIT, i/o devices

The criteria for drift/latency can only be established after we gone
through the above. The low-power stuff adds additional complexity.

We may need to dynamically change timer interpolators / time sources if
the power situation changes. Nothing like that exists today for time
interpolators since they are mostly used in server configurations.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-26 17:42    [W:0.045 / U:4.340 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site