From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Arnd Bergmann <arnd@kernel.org>,
linux-alpha@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Richard Henderson <richard.henderson@linaro.org>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Marc Zyngier <maz@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Michael Cree <mcree@orcon.net.nz>,
Frank Scheiner <frank.scheiner@web.de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10
Date: Thu, 30 May 2024 23:59:27 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2405302248550.23854@angie.orcam.me.uk> (raw)
In-Reply-To: <5567ab2e-80af-4c5f-bebb-d979e8a34f49@paulmck-laptop>
On Wed, 29 May 2024, Paul E. McKenney wrote:
> > What I have been after actually is: can you point me at a piece of code
> > in our tree that will cause an issue with a non-BWX Alpha as described in
> > your scenario, so that I have a starting point? Mind that I'm completely
> > new to RCU as I didn't have a need to research it before (though from a
> > skim over Documentation/RCU/rcu.rst I understand what its objective is).
>
> See the uses of the fields of the current->rcu_read_unlock_special.b
> anonymous structure for the example that led us here. And who knows how
> many other pieces of the Linux kernel that assume that it is possible
> to atomically store a single byte.
Thanks, that helps.
> Many of which use a normal C-language store, in which case there are
> no accessors. This can be a problem even in the case where there are no
> data races to either byte, because the need for the read-modify-write
> sequence on older Alpha systems results in implicit data races at the
> machine-word level.
Ack.
> > FWIW even if it was only me I think that depriving the already thin Alpha
> > port developer base of any quantity of the remaining manpower, by dropping
> > support for a subset of the hardware available, and then a subset that is
> > not just as exotic as the original i386 became to the x86 platform at the
> > time support for it was dropped, is only going to lead to further demise
> > and eventual drop of the entire port.
>
> Yes, support has been dropped for some of the older x86 CPUs as well,
> for example, Linux-kernel support for multiprocessor 80386 systems was
> dropped a great many years ago, in part because those CPUs do not have
> a cmpxchg instruction. So it is not like we are picking on Alpha.
That's what I mentioned (and for the record i386 wasn't dropped for the
lack of CMPXCHG, as we never supported i386 SMP, exceedingly rare, anyway,
but for the lack of page-level write-protection in the kernel mode, which
implied painful manual checks). At the time our support for the i386 was
dropped its population outside embedded use was minuscule and certainly
compared to non-i386 x86 Linux user base. And the supply of modern x86
systems was not an issue either.
Conversely no new Alpha systems are made and I suspect the ratio between
BWX and non-BWX Alpha Linux users is not as high as between post-i386 x86
and original i386 Linux users at the time of the drop.
> > And I think it would be good if we kept the port, just as we keep other
> > ports of historical significance only, for educational reasons if nothing
> > else, such as to let people understand based on an actual example, once
> > mainstream, the implications of weakly ordered memory systems.
>
> I don't know of any remaining issues with the newer Alpha systems that do
> support single-byte and double-byte load and store instructions, and so
> I am not aware of any reason for dropping Linux-kernel support for them.
Well, the lack of developers to maintain the port would be the reason I
refer to. If you let developers drop by preventing them from using their
hardware to work on the port, then eventually we'll have none.
Anyway it seems like an issue to be sorted in the compiler, transparently
to RCU, so it shouldn't be a reason to drop support for non-BWX Alpha CPUs
anymore. See my reply to Linus in this thread.
Thank you for your input, always appreciated.
Maciej
next prev parent reply other threads:[~2024-05-30 22:59 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 8:11 [PATCH 00/14] alpha: cleanups for 6.10 Arnd Bergmann
2024-05-03 8:11 ` [PATCH 01/14] alpha: sort scr_mem{cpy,move}w() out Arnd Bergmann
2024-05-03 8:11 ` [PATCH 02/14] alpha: fix modversions for strcpy() et.al Arnd Bergmann
2024-05-03 8:11 ` [PATCH 03/14] alpha: add clone3() support Arnd Bergmann
2024-05-03 8:11 ` [PATCH 04/14] alpha: don't make functions public without a reason Arnd Bergmann
2024-05-03 8:11 ` [PATCH 05/14] alpha: sys_sio: fix misspelled ifdefs Arnd Bergmann
2024-05-03 8:11 ` [PATCH 06/14] alpha: missing includes Arnd Bergmann
2024-05-03 8:11 ` [PATCH 07/14] alpha: core_lca: take the unused functions out Arnd Bergmann
2024-05-03 8:11 ` [PATCH 08/14] alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest Arnd Bergmann
2024-05-03 8:11 ` [PATCH 09/14] alpha: trim the unused stuff from asm-offsets.c Arnd Bergmann
2024-05-03 8:11 ` [PATCH 10/14] alpha: remove DECpc AXP150 (Jensen) support Arnd Bergmann
2024-05-03 16:07 ` Linus Torvalds
2024-05-03 17:00 ` Al Viro
2024-05-03 20:07 ` Arnd Bergmann
2024-05-03 8:11 ` [PATCH 11/14] alpha: sable: remove early machine support Arnd Bergmann
2024-05-03 8:11 ` [PATCH 12/14] alpha: remove LCA and APECS based machines Arnd Bergmann
2024-05-03 8:11 ` [PATCH 13/14] alpha: cabriolet: remove EV5 CPU support Arnd Bergmann
2024-05-03 8:11 ` [PATCH 14/14] alpha: drop pre-EV56 support Arnd Bergmann
2024-05-04 15:00 ` Richard Henderson
2024-05-06 10:06 ` Arnd Bergmann
2024-06-03 6:02 ` Jiri Slaby
2024-06-04 13:58 ` Greg KH
2024-05-03 16:06 ` [PATCH 00/14] alpha: cleanups for 6.10 Matt Turner
2024-05-03 20:15 ` Arnd Bergmann
2024-05-06 9:16 ` Michael Cree
2024-05-06 10:11 ` Arnd Bergmann
2024-05-03 16:53 ` John Paul Adrian Glaubitz
2024-05-03 17:19 ` Paul E. McKenney
2024-05-27 23:49 ` Maciej W. Rozycki
2024-05-28 14:43 ` Paul E. McKenney
2024-05-29 18:50 ` Maciej W. Rozycki
2024-05-29 22:09 ` Paul E. McKenney
2024-05-30 22:59 ` Maciej W. Rozycki [this message]
2024-05-31 3:56 ` Maciej W. Rozycki
2024-05-31 19:33 ` Paul E. McKenney
2024-06-03 16:22 ` Maciej W. Rozycki
2024-06-03 17:08 ` Paul E. McKenney
2024-07-01 23:50 ` Maciej W. Rozycki
2024-05-30 1:08 ` Linus Torvalds
2024-05-30 22:57 ` Maciej W. Rozycki
2024-05-31 0:10 ` Linus Torvalds
2024-06-03 11:09 ` Maciej W. Rozycki
2024-06-03 11:36 ` John Paul Adrian Glaubitz
2024-06-03 16:57 ` Linus Torvalds
2024-07-01 23:48 ` Maciej W. Rozycki
2024-05-31 15:48 ` Arnd Bergmann
2024-05-31 16:32 ` Linus Torvalds
2024-05-31 16:54 ` Arnd Bergmann
2024-06-01 13:51 ` David Laight
2024-07-01 23:48 ` Maciej W. Rozycki
2024-07-02 1:13 ` Linus Torvalds
2024-07-03 0:12 ` Maciej W. Rozycki
2024-07-03 0:50 ` Linus Torvalds
2024-07-04 22:21 ` Maciej W. Rozycki
2024-06-03 11:33 ` Maciej W. Rozycki
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=alpine.DEB.2.21.2405302248550.23854@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=frank.scheiner@web.de \
--cc=glaubitz@physik.fu-berlin.de \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=maz@kernel.org \
--cc=mcree@orcon.net.nz \
--cc=paulmck@kernel.org \
--cc=richard.henderson@linaro.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).