Re: long delays (possibly infinite) in time_interpolator_get_counter

[Christoph Lameter <clameter@engr.sgi.com>]

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 
source.

>    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.