Re: [PATCH v5] x86/hpet: Reduce HPET counter read contention
From: Waiman Long
Date: Fri Aug 12 2016 - 18:59:14 EST
On 08/12/2016 05:44 PM, Dave Hansen wrote:
On 08/12/2016 02:25 PM, Waiman Long wrote:
+ do {
+ cpu_relax();
+ new.lockval = READ_ONCE(hpet.lockval);
+ } while ((new.value == old.value)&& raw_spin_is_locked(&new.lock));
While it gets more far-fetched, this isn't guaranteed to make progress
until the saved HPET value actually changes. You could have a constant
stream of other CPUs going and doing hpet_readl() (and getting the same
value back from a sloooow HPET). So each time through this loop, this
processor sees (new.value == old.value), and sees the lock held.
That is the point. All CPUs that try to read the HPET simultaneously
will get the same value back instead of waiting in line to get a
slightly different value. They do need to wait until the lock holder
read the new HPET value. If you have n CPUs trying to read HPET and the
read latency is T, the latency for all the CPUs to read it is just T
instead of a worst case latency of nT or an average of (n+1)T/2.
What we don't want to see is to return some stale value that make it
looks like we go backward in time.
Cheers,
Longman