Re: Fwd: [PATCH v2] bcache: use bio cloning for detached device requests

[Stephen Zhang]

Coly Li <colyli@xxxxxxxxx> 于2026年1月21日周三 09:34写道：
>
> On Tue, Jan 20, 2026 at 08:01:52AM +0800, Jens Axboe wrote:
> > On 1/20/26 7:46 AM, Coly Li wrote:
> > >> @@ -949,6 +950,11 @@ static int bcache_device_init(struct
> > >> bcache_device *d, unsigned int block_size,
> > >>                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER))
> > >>                 goto out_ida_remove;
> > >>
> > >> +       if (bioset_init(&d->bio_detach, 4,
> > >                                     ^^^^^-> I feel 4 might be a bit small
> > > here. bio_detached set is for normal IO when backing device is not
> > > attached to a cache device. I would suggest to set the pool size to
> > > 128 or 256.
> >
> > Absolutely not, 4 is more than plenty. The pool elements are only ever
> > used if allocations fail, to guarantee forward progress. Setting aside
> > 128 or 256 for that case is utterly wasteful, you only need a couple. 4
> > is a good number, if anything it should be smaller (2).
>
> Hi Jens,
>
> Thanks for the information. Please correct me if I am wrong for the following
> text,
> - If the backing is a normal SSD raid0, the IOPS without attached cache device
> might be more than thousands. In this case, I assume 128 or 256 might be more
> tolerant.
> - I see what ‘4’ means, just not sure/comfortable when memory pressure is high.
> And reserving 128/256 will occupy around 0.5~1MB memory, I feel such extra
> memory is acceptable in bcache use case.
>
> Don't get me wrong, I totally trust you. If '4' works well enough for high
> memory pressure condition for detached bcache device, it is cool.
>
> Thanks in advance.
>
> Coly Li

Hi Jens, Coly,

Regarding the discussion on the bio_detached pool size: while 4 is
sufficient to guarantee forward progress, some high-load environments
may prefer a larger reserve to minimize allocation latency under
extreme memory pressure.

To provide a middle ground, I propose adding a generic bioset_resize()
interface to the block layer and exposing it through a new bcache
sysfs attribute 'detached_pool_size'.

This allows us to keep the default value conservative (e.g., 4) to
avoid unnecessary memory overhead, while giving users the flexibility
to tune the emergency reserves based on their specific hardware and
workload requirements.

The patch is attached below. Does this look like a reasonable
compromise?

Thanks,
Shida
------------