All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Boris Burkov <boris@bur.io>, David Sterba <dsterba@suse.cz>
Cc: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] btrfs: get rid of btrfs_(alloc|free)_compr_folio()
Date: Fri, 6 Mar 2026 09:13:23 +1030	[thread overview]
Message-ID: <63e3b64e-e344-4d90-bcfa-ecc686b85c5f@gmx.com> (raw)
In-Reply-To: <20260305174609.GC926642@zen.localdomain>



在 2026/3/6 04:16, Boris Burkov 写道:
[...]
>> So I stand by the reason of the pool but with the evolution of folios
>> and bs < ps the cost could be too high. I can still see the pool for a
>> subset of the combinations for some common scenario like 4K block size
>> on 64K page host (e.g. ARM).
>>
> 
> FWIW, we do already see issues with allocation in compressed IO in
> production, so I am hesitant to support this change.

May I ask how frequent the problem is, and what's the CPU arch?
Finally is it only happening after commit 6f706f34fc4c ("btrfs: switch 
to btrfs_compress_bio() interface for compressed writes"), aka v7.0 kernel.

I tried my best locally to introduce extra ASSERT()s to make sure every 
folio inside a compressed bio has a ref of 1, but it hasn't yet 
triggered inside zlib_compress_bio().

Thanks,
Qu

> 
> On the one hand, we have the issues so the pool is not completely saving
> us anyway. On the other hand, removing it seems likely to make this worse
> in the way that you predict, Dave.
> 
> If we do move forward with this, I will try to watch such errors closely
> on the first release of a kernel without the pool.
> 
> Thanks,
> Boris
> 
>>> And hopefully this will address David's recent crash (as usual I'm not
>>> able to reproduce locally).
>>
>> I'll run the test with this patch.
> 


  reply	other threads:[~2026-03-05 22:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02  8:00 [PATCH RFC] btrfs: get rid of btrfs_(alloc|free)_compr_folio() Qu Wenruo
2026-03-05  2:56 ` David Sterba
2026-03-05  3:09   ` David Sterba
2026-03-05  4:33     ` Qu Wenruo
2026-03-05 17:46   ` Boris Burkov
2026-03-05 22:43     ` Qu Wenruo [this message]
2026-03-05 22:45       ` Boris Burkov

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=63e3b64e-e344-4d90-bcfa-ecc686b85c5f@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=boris@bur.io \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.