Messages in this thread | | | Date | Fri, 12 Aug 2016 17:32:01 -0400 | From | Waiman Long <> | Subject | Re: [RESEND PATCH v4] x86/hpet: Reduce HPET counter read contention |
| |
On 08/12/2016 05:16 PM, Dave Hansen wrote: > On 08/12/2016 01:18 PM, Andy Lutomirski wrote: >> I don't think this is right. If the HPET ever returns the same value >> twice in a row (unlikely because it's generally too slow to read, but >> it's plausible that someone will make a fast HPET some day), then this >> could deadlock. > True... > > I guess that means we've got to do some kind of sequence counter > preferably in the same cacheline as the HPET value itself, or _something > that we guarantee to change on each write to the cached value.
I have done something similar in the v5 patch that I just sent out.
>> Also, does this code need to be NMI-safe? This implementation is >> deadlocky if it's called from an NMI. > Urg. Can't we just do > > if (in_nmi()) > return read_real_hpet(); > > ?
Yes, I am doing that in my v5 patch.
>> The original code was wait-free, right? That was a nice property, too. > You mean no spins? I don't think this one really spins ever either. >
In the contended case, the reader needs to wait until the new HPET value is available. I consider this a kind of waiting.
Cheers, Longman
| |