lkml.org 
[lkml]   [2017]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 4/6] arch/sparc: Enable queued rwlocks for SPARC
From
Date

On 5/19/2017 4:03 AM, Peter Zijlstra wrote:
> On Thu, May 18, 2017 at 10:31:13PM -0400, David Miller wrote:
>> From: Babu Moger <babu.moger@oracle.com>
>> Date: Thu, 18 May 2017 18:36:08 -0600
>>
>>> @@ -82,6 +82,7 @@ config SPARC64
>>> select HAVE_ARCH_AUDITSYSCALL
>>> select ARCH_SUPPORTS_ATOMIC_RMW
>>> select HAVE_NMI
>>> + select ARCH_USE_QUEUED_RWLOCKS
>>>
>> If you are selecting this on SPARC64 all the time, then:
>>
>>> @@ -94,6 +94,7 @@ static inline void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long fla
>>> : "memory");
>>> }
>>>
>>> +#ifndef CONFIG_QUEUED_RWLOCKS
>>> /* Multi-reader locks, these are much saner than the 32-bit Sparc ones... */
>> You can remove this segment of ifdef'd code altogether since it is in
>> a sparc64 specific header file.
>
> So IIRC Sparc v8 only has that single byte load-and-set (or swap)
> instruction, right? That means you can only make test-and-set spinlocks
> and then have to build the world on top of that.
>
> I don't see qrwlock -- which assumes the spinlock implementation is fair
> -- making much sense for that.
>
> Also, IIRC Sparc-v8 didn't really have very big SMP systems, those came
> with v9. And qspinlock only really makes sense on the bigger systems
> (not to mention that building the qspinlock on top of atomic operations
> build on test-and-set spinlocks just seems extremely dysfunctional).
>
>
> In any case, I think what I'm saying is that it makes sense to make this
> a Sparcv9 only feature.
>

Agree. Lets keep this as Sparcv9 only feature.

\
 
 \ /
  Last update: 2017-05-19 18:44    [W:0.069 / U:0.148 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site