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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |