[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-kernel
Subject: Re: long delays (possibly infinite) in time_interpolator_get_counter
From: Christoph Lameter <clameter () engr ! sgi ! com>
Date: 2005-07-31 20:00:12
Message-ID: Pine.LNX.4.62.0507311256440.32674 () schroedinger ! engr ! sgi ! com
[Download RAW message or body]
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic