Re: [PATCH v3] bcache: dynamic incremental gc

[Zou Mingzhe <mingzhe.zou@easystack.cn>]

在 2022/5/24 01:55, Eric Wheeler 写道:
> 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
>
Hi, Eric

I tested each case 5 times and used the last result to make this graph, 
you can check the raw data.

The first 4 times results also have graph in the raw data, you can also 
find some spikes over  2000us on the "NO GC" side.

So, I don't think the 3000us "spike" at 40s are a problem, it just looks 
like a system fluctuation.

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