Re: long delays (possibly infinite) in time_interpolator_get_counter

[Christoph Lameter]

What you are dealing with is a machine that is using ITC as a time bases. 
That is a special case. The fix should not affect machines that have a 
proper time source. More below. You can circumvent the compensation for 
ITC inaccuracies by specifying "nojitter" on the kernel command if you are 
willing to take the risk of slightly inaccurate time.

On Fri, 29 Jul 2005 tony.luck@xxxxxxxxx wrote:
> The patch below makes things less bad by not letting Y & Z do the cmpxchg if
> they are going to fail the read_seqretry() test anyway.  But it is very ugly
> to do this extra test on xtime_lock ... so I'm hoping that someone can come
> up with something better.

Well get a proper time source and do not use ITC for a time source in an 
SMP system. Got HPET hardware?

> -extern unsigned long time_interpolator_get_offset(void);
> +extern unsigned long time_interpolator_get_offset(long);

This is going to cause unnecessary overhead for non ITC users.

> -		nsec = xtime.tv_nsec+time_interpolator_get_offset();
> +		nsec = xtime.tv_nsec+time_interpolator_get_offset(seq);

Here it is.

> -		offset = time_interpolator_get_offset();
> +		offset = time_interpolator_get_offset(seq);

and here again.

> +			/*
> +			 * If our caller is going to ignore us and retry, then
> +			 * don't burn up the bus with the cmpxchg
> +			 */
> +			if (seq && unlikely(read_seqretry(&xtime_lock, seq)))
> +				return now;

Two read_seqretries() for one  read_seqbegin()? That its unusual to say 
the least.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/