Re: [RFC PATCH] bcache: reduce gc latency by processing less nodes and sleep less time

Hi Coly,

Thank you for your new patch. I have reviewed the patch, and it is
much simpler and cleaner indeed.

In addition, I have run the 24-hour stress tests and can confirm that
it brings noticeable performance improvement. For our 4kb writethrough
workload, your patch further reduces the median (P50) latency during
garbage collection from about 20 ms in the previous approach [1] to 4
ms [2]. And I did not observe any issues during my testing.

This is a great step forward. I look forward to seeing this patch
submitted soon. And please feel free to add me to the sign-off list if
it fits.

Best regards,
Robert Pang

[1] https://gist.github.com/robert-pang/a22b7c5dee2600be3260f4db57e5776d
[2] https://gist.github.com/robert-pang/05b17921a83d59afc8aab28b5d9e9e0d

On Thu, Aug 28, 2025 at 9:25 AM Coly Li <[email protected]> wrote:
>
> Hi Robert,
>
> Your patch breaks the emwa_add() method to maintain the gc stats numbers. So I have to look for another method but try to get similar benchmark results as yours did.
>
>  Hi Mingzhe,
>
> The dynamic sleep interval and gc nodes patch is kind of over complicated IMHO. So I compose a simplified one based on the idea from you and Robert.
>
>
> Can you all help to review and test this RFC patch? Hope it may work out. Thanks for your help in advance.
>
> Coly Li
>
>
>
> > 2025年8月29日 00:16，[email protected] 写道：
> >
> > When bcache device is busy for high I/O loads, there are two methods to
> > reduce the garbage collection latency,
> > - Process less nodes in eac loop of incremental garbage collection in
> >  btree_gc_recurse().
> > - Sleep less time between two full garbage collection in
> >  bch_btree_gc().
> >
> > This patch introduces to hleper routines to provide different garbage
> > collection nodes number and sleep intervel time.
> > - btree_gc_min_nodes()
> >  If there is no front end I/O, return 128 nodes to process in each
> >  incremental loop, otherwise only 10 nodes are returned. Then front I/O
> >  is able to access the btree earlier.
> > - btree_gc_sleep_ms()
> >  If there is no synchronized wait for bucket allocation, sleep 100 ms
> >  between two incremental GC loop. Othersize only sleep 10 ms before
> >  incremental GC loop. Then a faster GC may provide available buckets
> >  earlier, to avoid most of bcache working threads from being starved by
> >  buckets allocation.
> >
> > The idea is inspired by works from Mingzhe Zou and Robert Pang, but much
> > simpler and the expected behavior is more predictable.
> >
> > Signed-off-by: Coly Li <[email protected]>
> > Cc: Robert Pang <[email protected]>
> > Cc: Mingzhe Zou <[email protected]>
> > ---
>
> [snipped]
>