Re: long delays (possibly infinite) in time_interpolator_get_counter

[Christoph Lameter]

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/