public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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