All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Russell King <linux@armlinux.org.uk>,
	Ingo Molnar <mingo@redhat.com>, Waiman Long <longman@redhat.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 0/3] Queued spinlocks/RW-locks for ARM
Date: Tue, 8 Oct 2019 21:32:07 +0200	[thread overview]
Message-ID: <20191008193207.intucfnfuitudadx@flow> (raw)
In-Reply-To: <CAK8P3a13AOKm1epqAtP9329Ai2Bh+H18fOfsqO+deCLTHoYRwA@mail.gmail.com>

On 2019-10-08 13:42:43 [+0200], Arnd Bergmann wrote:
> This looks nice, and I don't see anything wrong with the implementation,
> but I am slightly worried about switching everything over to a generic
> spinlock while keeping the custom ARM version for an exceptionally
> rare corner case:

I do not want ARM to have two spinlock implementations.

> The ARM spinlock is now only used when you build an SMP-enabled
> kernel for an ARM1136r0 that is used in OMAP2, i.MX3 and some
> of the least common Integrator/Realview variants. I'm not aware
> of any binary distros with ARMv6+ kernels, so these would run custom
> kernels that are almost always non-SMP as well as no longer getting
> kernel upgrades (almost all have been discontinued years ago, the i.MX35
> chip itself was the last to get EOLd in 2018).
> Raspbian builds an ARMv6K SMP kernel that is not affected by this.

I just looked at the Debian configs. The armel look UP only and armhf is
V7. I am not sure if there is a SMP capable CPU that is V6. I've been
looking at a wiki [0] and the first SMP CPU seems to be ARMv6K.

> I wonder if we can do something better here and make the
> asm-generic/qspinlock.h implementation always degrade into an
> equivalent of include/linux/spinlock_up.h when running on uniprocessor
> systems, avoiding both the atomic cmpxchg and the slowpath.
> 
> That way, an ARMv6+SMP kernel on UP could share the qspinlock
> implementation but never actually get into the invalid 16-bit xchg() or
> sev()/wfe(). It already shouldn't ever get into the slowpath on a
> non-SMP system if I understand it correctly, but avoiding the cmpxchg()
> entirely would be an added benefit.

The lock should never be contenteded so yes.

[0] https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures

>        Arnd

Sebastian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      parent reply	other threads:[~2019-10-08 19:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 21:44 [RFC PATCH 0/3] Queued spinlocks/RW-locks for ARM Sebastian Andrzej Siewior
2019-10-07 21:44 ` [PATCH 1/3] ARM: Use qrwlock implementation Sebastian Andrzej Siewior
2019-10-07 21:44 ` [PATCH 2/3] ARM: Use qspinlock implementation Sebastian Andrzej Siewior
2019-10-07 21:44 ` [PATCH 3/3] ARM: Inline locking functions for !PREEMPTION Sebastian Andrzej Siewior
2019-10-08 11:42 ` [RFC PATCH 0/3] Queued spinlocks/RW-locks for ARM Arnd Bergmann
2019-10-08 13:36   ` Waiman Long
2019-10-08 14:32     ` Arnd Bergmann
2019-10-08 19:47       ` Sebastian Andrzej Siewior
2019-10-08 21:47         ` Arnd Bergmann
2019-10-08 22:02           ` Sebastian Andrzej Siewior
2019-10-09  8:15             ` Arnd Bergmann
2019-10-09  8:46       ` Peter Zijlstra
2019-10-09  8:57         ` Arnd Bergmann
2019-10-09  9:31           ` Peter Zijlstra
2019-10-09 10:31             ` Arnd Bergmann
2019-10-09 10:56               ` Peter Zijlstra
2019-10-09 12:00                 ` Arnd Bergmann
2019-10-09 12:06                   ` Peter Zijlstra
2019-10-09 12:52                     ` Will Deacon
2019-10-09 13:50                     ` Arnd Bergmann
2019-10-09 21:42                       ` Sebastian Andrzej Siewior
2019-10-08 19:32   ` Sebastian Andrzej Siewior [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191008193207.intucfnfuitudadx@flow \
    --to=sebastian@breakpoint.cc \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.