Re: [PATCH v3] bcache: dynamic incremental gc

[Eric Wheeler <bcache@lists.ewheeler.net>]

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

On Mon, 23 May 2022, Zou Mingzhe wrote:
> 在 2022/5/23 10:52, Zou Mingzhe 写道:
> > 在 2022/5/21 02:24, Eric Wheeler 写道:
> >> On Fri, 20 May 2022, Zou Mingzhe wrote:
> >>
> >> Questions:
> >>
> >> 1. Why is the after-"BW NO GC" graph so much flatter than the before-"BW
> >>     NO GC" graph?  I would expect your control measurements to be about the
> >>     same before vs after.  You might `blkdiscard` the cachedev and
> >>     re-format between runs in case the FTL is getting in the way, or maybe
> >>     something in the patch is affecting the "NO GC" graphs.
> >> 2. I wonder how the latency looks if you zoom into to the latency graph:
> >>     If you truncate the before-"LATENCY DO GC" graph at 3000 us then how
> >>     does the average latency look between the two?
> >> 3. This may be solved if you can fix the control graph issue in #1, but
> >>     the before vs after of "BW DO GC" shows about a 30% decrease in
> >>     bandwidth performance outside of the GC spikes.  "IOPS DO GC" is lower
> >>     with the patch too.  Do you think that your dynamic incremental gc
> >>     algorithm be tuned to deal with GC latency and still provide nearly the
> >>     same IOPS and bandwidth as before?
> >>
> >>
> >> -- 
> >> Eric Wheeler
> 
> Hi Eric,
> 
> I have done a retest round and update all data on
> "https://gist.github.com/zoumingzhe/69a353e7c6fffe43142c2f42b94a67b5".
> 
> First, there is only this patch between before and after, I re-format the disk
> with make-bcache before each fio. Each case was tested 5 times, and the
> results are as follows:
> 
>                     before after
>       NO GC           DO GC          NO GC          DO GC
> 1    99162.29     97366.28     99970.89     98290.81
> 2    99897.80     97879.99     96829.14     95548.88
> 3    98183.49     98834.29     101508.06   98581.53
> 4    98563.17     98476.61     96866.40     96676.87
> 5    97059.91     98356.50     96248.10     94442.61
> 
> Some details are also shown in the new graph, in addition to the raw data
> available for download.
> 
> I confirm that this patch does not cause a drop in iops. We have some other
> patches that may have affected the previous test, but this patch works fine.

Looks great, glad to see that it performs well!

What is the 3000us spike on the "after" line of "LATENCY DO GC" at about 
t=40s ? There is a drop in IOPS and BW on the other graphs at t=40s, too, 
but I don't see the same behavior on the "NO GC" side.

-Eric

> 
> 
> In fact, we mostly modified the gc handling.
> 
> mingzhe
> 
> 
> 
> 
> 
> 
> 
> 
>