Re: long delays (possibly infinite) in time_interpolator_get_counter

From: Christoph Lameter
Date: Sun Jul 31 2005 - 15:03:57 EST

On Sun, 31 Jul 2005, Alex Williamson wrote:

> Ok, here's an optimization that should help reduce contention on the
> cmpxchg, has zero impact on the nojitter path, and doesn't require any
> changes to fsys. When a caller already had the xtime_lock write lock
> there's no need to fight with other CPUs for the cmpxchg. The other

Yup correct.

> "reader" CPUs will have to fetch it again since a seqlock write is in
> progress. Therefore we can simplify this path as shown below. The
> write is atomic, and we don't care if another CPU has changed last_cycle
> since it can't return the value until the write lock is released. This
> has only been compile tested, but I'm interested to hear your opinion.

time_interpolator_get_counter is static inline. So you may modify the
existing function and pass a constant parameter without a
performance reduction. Two different versions will then be generated for
time_interpolator_get_counter at compile time.

Maybe call the parameter "writelock"?

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