Re: [PATCH RFC] btrfs: get rid of btrfs_(alloc|free)_compr_folio()

[Boris Burkov <boris@bur.io>]

On Fri, Mar 06, 2026 at 09:13:23AM +1030, Qu Wenruo wrote:
> 
> 
> 在 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
> 

I'm sorry, I didn't mean to give you the wrong impression.

I have not seen the bug you and Dave have been hunting.

I meant generic allocation issues in more complex paths involving
writeback/reclaim/page faults, etc that Dave was warning about with
removing the compr pool.

Thanks,
Boris

> > 
> > 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.
> > 
>