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/
