From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Endless "reclaiming chunk"/"relocating block group"
Date: Thu, 20 Oct 2022 09:53:10 -0400 [thread overview]
Message-ID: <Y1FSxogPeNIUfyVn@hungrycats.org> (raw)
In-Reply-To: <1666262200@msgid.manchmal.in-ulm.de>
On Thu, Oct 20, 2022 at 01:01:48PM +0200, Christoph Biedl wrote:
> Thanks for add the toughts shared ...
>
> Zygo Blaxell wrote...
>
> (...)
> > It makes me think of possible rounding errors (e.g. the threshold
> > calculation divides by 100, or there's a sum of quantities that leads
> > to a percentage > 100, but the code treats zero as a special case and
> > bails out long before, so I don't see how we'd reach those corner cases.
>
> Out of desperation, I followed an approach I could read between the lines
> here. The thing I did not mention (just because I forgot about it) is
> the compiler version used to build the kernel. For reasons, this is
> still a gcc-5 (5.4.0, to be precise). After a rebuild using gcc-11,
> things are nice and smooth.
That's...not the weirdest thing I've ever seen, but maybe the weirdest
thing I've seen this month.
> Now I cannot deny I'm quite confused. Assuming this is really the cause,
> how should I go from here? I can patch the sources at will, but it's a
> huge amount of code, and I don't even know where is start. Also from
> expericence, debug print statements do bar the optimizer from creating
> the problematic instructions.
That in itself would (weakly) confirm a compiler issue. But it might
be simpler than that, like a bug in the implementation of a math builtin
that wasn't popular in the kernel 8 years ago, but is popular now after
the implementation was debugged in GCC. I don't know if that's the case
in this instance, but similar things have happened in the past.
> Christoph
>
> FWIW, according to Documentation/process/changes.rst, that old gcc-5 is
> considered sufficient. I didn't expect that :)
On paper maybe, but maybe not in real-world use. Somewhat related thread
on linux-kernel:
https://lore.kernel.org/all/Y0hz3u8ZNO2yFU2f@sirena.org.uk/T/
TL;DR not enough people are testing new kernel code against old compilers.
If it's problematic to keep the host system's gcc up to date, a build
chroot for kernel building with an up to date toolchain is the way to go.
next prev parent reply other threads:[~2022-10-20 13:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 18:29 Endless "reclaiming chunk"/"relocating block group" Christoph Biedl
2022-10-20 1:59 ` Zygo Blaxell
2022-10-20 11:01 ` Christoph Biedl
2022-10-20 13:53 ` Zygo Blaxell [this message]
2022-11-24 18:33 ` Christoph Biedl
2022-11-24 19:14 ` Christoph Biedl
2022-10-20 9:16 ` Filipe Manana
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=Y1FSxogPeNIUfyVn@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel.bfrz@manchmal.in-ulm.de \
/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