From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: paulmck@kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Linux-Arch <linux-arch@vger.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>
Subject: Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
Date: Mon, 13 May 2024 09:10:11 +0200 [thread overview]
Message-ID: <ca22cfceb465dcbc336f51621f844593aa45619f.camel@physik.fu-berlin.de> (raw)
In-Reply-To: <a8241a71-2b7d-4be0-8772-5c3b40fb5302@paulmck-laptop>
Hello,
On Sun, 2024-05-12 at 07:44 -0700, Paul E. McKenney wrote:
> On Sun, May 12, 2024 at 08:02:59AM +0200, John Paul Adrian Glaubitz wrote:
> > On Sat, 2024-05-11 at 18:26 -0700, Paul E. McKenney wrote:
> > > And that breaks things because it can clobber concurrent stores to
> > > other bytes in that enclosing machine word.
> >
> > But pre-EV56 Alpha has always been like this. What makes it broken
> > all of a sudden?
>
> I doubt if it was sudden. Putting concurrently (but rarely) accessed
> small-value quantities into single bytes is a very natural thing to do,
> and I bet that there are quite a few places in the kernel where exactly
> this happens. I happen to know of a specific instance that went into
> mainline about two years ago.
But it's treated like it happened all of a sudden instead of taking the way
of a proper phaseout. That's what I am criticizing.
> > We could actually ask Ulrich Teichert what the current state is
> > on his Jensen machine.
>
> Please feel free to do so.
>
> And if the ability to run current mainline reliably on these systems
> is so very important to you, please also feel free to look into ways of
> fixing this issue within the confines of the Alpha-specific code rather
> than attempting to continue placing this outdated constraint on the rest
> of the kernel.
Well, we have had a similar discussion just a few months before with the
ia64 removal. But in that case we agreed that a good compromise would be
to slate the removal for an LTS release so that users would be able to use
an LTS kernel on these machines.
I'm not sure why this shouldn't be possible in this case as well.
> Yes, it is no longer the year 1973, but it still is the case that using
> four bytes (or, worse yet, per Arnd, eight bytes) where one byte will
> do is wasting a huge amount of resources across the billions of systems
> on which the Linux kernel runs. So again, if running current mainline
> on these decades-old systems is so very important to you, please figure
> out a way to do so that isn't quite so wasteful of resources.
The way this whole change was pushed through doesn't sound like you're willing
to give people the time to find an alternative solution. The pre-EV56 removal
was pushed through without any further discussion with the claim that pre-EV56
support is broken.
Is that not something that can be criticized?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
next prev parent reply other threads:[~2024-05-13 7:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <71feb004-82ef-4c7b-9e21-0264607e4b20@app.fastmail.com>
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes for 6.10 Arnd Bergmann
2024-05-10 21:40 ` John Paul Adrian Glaubitz
2024-05-10 22:28 ` Paul E. McKenney
2024-05-11 18:49 ` John Paul Adrian Glaubitz
2024-05-11 19:37 ` Paul E. McKenney
2024-05-11 20:08 ` Arnd Bergmann
2024-05-12 1:26 ` Paul E. McKenney
2024-05-12 6:02 ` John Paul Adrian Glaubitz
2024-05-12 14:44 ` Paul E. McKenney
2024-05-13 3:50 ` Akira Yokosawa
2024-05-13 4:03 ` Paul E. McKenney
2024-05-13 6:28 ` Arnd Bergmann
2024-05-13 9:26 ` John Paul Adrian Glaubitz
2024-05-13 16:52 ` Ulrich Teichert
2024-05-13 21:44 ` John Paul Adrian Glaubitz
2024-05-13 7:10 ` John Paul Adrian Glaubitz [this message]
2024-05-12 6:17 ` John Paul Adrian Glaubitz
2024-05-13 16:27 ` Linus Torvalds
2024-05-13 21:42 ` John Paul Adrian Glaubitz
2024-05-31 2:53 ` Maciej W. Rozycki
2024-05-13 17:05 ` pr-tracker-bot
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=ca22cfceb465dcbc336f51621f844593aa45619f.camel@physik.fu-berlin.de \
--to=glaubitz@physik.fu-berlin.de \
--cc=arnd@arndb.de \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
--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).