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

\
 
 \ /
  Last update: 2017-05-19 11:04    [W:0.077 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site