public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Endless "reclaiming chunk"/"relocating block group"
Date: Thu, 20 Oct 2022 13:01:48 +0200	[thread overview]
Message-ID: <1666262200@msgid.manchmal.in-ulm.de> (raw)
In-Reply-To: <Y1Crh/Cz2rcbIayw@hungrycats.org>

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.

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.

    Christoph

FWIW, according to Documentation/process/changes.rst, that old gcc-5 is
considered sufficient. I didn't expect that :)

  reply	other threads:[~2022-10-20 11:01 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 [this message]
2022-10-20 13:53     ` Zygo Blaxell
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=1666262200@msgid.manchmal.in-ulm.de \
    --to=linux-kernel.bfrz@manchmal.in-ulm.de \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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