lkml.org 
[lkml]   [2016]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6] x86/hpet: Reduce HPET counter read contention
On 08/25/2016 02:50 PM, Dave Hansen wrote:
> On 08/12/2016 05:59 PM, Waiman Long wrote:
>> + * The lock and the hpet value are stored together and can be read in a
>> + * single atomic 64-bit read. It is explicitly assumed that arch_spinlock_t
>> + * is 32 bits in size.
> This requirement forces us to give up all of the goodness of lockdep.
> Is this strictly a performance optimization or is there some function
> requirement behind it as well?

Yes, it is mostly performance optimization. Using a full spinlock will
require additional synchronization code like a memory barrier to prevent
race between the lock and HPET value with respect to the readers.

It is a simple lock that won't have additional locks nested inside. So I
wonder if there is any value in having the lockdep functionality for
this lock.

Cheers,
Longman

\
 
 \ /
  Last update: 2016-09-17 09:57    [W:0.095 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site