Re: [PATCH v3] bcache: dynamic incremental gc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




在 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











[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux