From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Arnd Bergmann <arnd@kernel.org>,
linux-alpha@vger.kernel.org,
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: Mon, 3 Jun 2024 12:33:26 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2406031209560.9248@angie.orcam.me.uk> (raw)
In-Reply-To: <4bb50dc0-244a-4781-85ad-9ebc5e59c99a@app.fastmail.com>
On Fri, 31 May 2024, Arnd Bergmann wrote:
> I then tried changing the underlying variables to 32-bit ones
> to see how many changes are needed, but I gave up after around
> 150 of them, as I was only scratching the surface. To do this
> right, you'd need to go through each one of them and come up
> with a solution that is the best trade-off in terms of memory
> usage and performance for that one. There are of course
> others that should be using WRITE_ONCE() and are missing
> this, so the list is not complete either. See below for
> the ones I could find quickly.
Thank you for your attempt, and I agree this is excessive and beyond what
we can reasonably handle.
> > 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.
>
> I know you like you museum pieces to be older than everyone
> else's, and I'm sorry that my patch series is causing you
> problems, but I don't think the more general criticism is
> valid here. My hope was mainly to help our with both keeping
> Alpha viable for a few more years while also allowing Paul
> to continue with his RCU changes.
Appreciated and thank you for your appreciation as well.
> As far as I can tell, nobody else is actually using EV4
> machines or has been for years now, but the presence of that
> code did affect both the performance and correctness of the
> kernel code for all EV56+ users since distros have no way
> of picking the ISA level on alpha for a generic kernel.
Well, at least John Paul Adrian complained as well, and who knows who
else is there downstream. I'd expect most people (i.e. all except for
core Linux developers) not to track upstream development in a continuous
manner.
> The strongest argument I see for assuming non-BWX alphas
> are long dead is that gcc-4.4 added support for C11 style
> _Atomic variables for alpha, but got the stores wrong
> without anyone ever noticing the problem. Even one makes
> the argument that normal byte stores and volatiles ones
> should not need atomic ll/st sequenes, the atomics
> clearly do. Building BWX-enabled kernels and userland
> completely avoids this problem, which make debugging
> easier for the remaining users when stuff breaks.
This only shows the lack of proper verification here rather than just
use. I'm not even sure if the nature of this problem is going to make it
trigger in GCC regression testing. Which BTW I have wired my EV45 system
for in my lab last year and which would be going by now if not for issues
with support network automation equipment (FAOD, state of the art and
supported by the manufacturer). We shall see once I'm done.
As John Paul Adrian has pointed out the removal was expedited with no
attempt made to find a proper solution that would not affect other users.
As you can see it took me one e-mail exchange with Linus to understand
what the underlying issue has been and then just a little bit of thinking,
maybe half an hour, likely even less, to identify a feasible solution.
Yes, I could have come up with it maybe a month ago if I wasn't so much
behind on mailing list traffic. But it's not my day job and since we had
this issue for years now, it wasn't something that had to be handled as a
matter of urgency. We all are people and have our limitations. We could
have waited with the RFC out for another development cycle. This has been
the point of my complaint.
Maciej
prev parent reply other threads:[~2024-06-03 11:33 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
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 [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=alpine.DEB.2.21.2406031209560.9248@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).