在 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.
In fact, we mostly modified the gc handling.
mingzhe
