Re: long delays (possibly infinite) in time_interpolator_get_counter

From: Christoph Lameter
Date: Sat Jul 30 2005 - 13:13:43 EST

On Sat, 30 Jul 2005, Alex Williamson wrote:

> On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> > What you are dealing with is a machine that is using ITC as a time bases.
> > That is a special case.
> The default time source for ia64 systems is a "special case"? 4
> socket and smaller boxes typically do not have any other time source.

It is a special case because we typically use other time sources. The
limitations of cycle counters in SMP environments are well known and most
hardware manufacturers have dealt with this issue by using another clock

> And what if you don't have any HPET and aren't willing to take that
> risk? We need a solution that works with all time sources. A system
> with the default time source should not hang or have unreasonable delays
> with the standard setup. Why is a synchronized ITC driven from a common
> clock such a terrible time source for small systems

If it is really synchronized then you can run with "nojitter" without any
issue. Then you wont have to deal with the cmpxchg and everything is fine.
But I suspect that the ITC are NOT truly synchronized (it has an
"offset" that may be nonzero right?) otherwise you would have used nojitter.

> in progress. In any case, I think we need to focus on a solution that
> works well on all systems, not just those with extra timer hardware.

Extra timer hardware is necessary to fix the ITC deficiency. You are at
the source of the problem. Fix the damn hardware to provide a standardized
synchronized clock or provide a truly synchronized ITC.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at