> 2024年5月4日 02:23，Coly Li <colyli@xxxxxxx> 写道： > > > >> 2024年4月11日 14:44，Robert Pang <robertpang@xxxxxxxxxx> 写道： >> >> HI Coly >> >> Thank you for submitting it in the next merge window. This patch is >> very critical because the long IO stall measured in tens of seconds >> every hour is a serious issue making bcache unusable when it happens. >> So we look forward to this patch. >> >> Speaking of this GC issue, we gathered the bcache btree GC stats after >> our fio benchmark on a 375GB SSD cache device with 256kB bucket size: >> >> $ grep . /sys/fs/bcache/31c945a7-d96c-499b-945c-d76a1ab0beda/internal/btree_gc_* >> /sys/fs/bcache/31c945a7-d96c-499b-945c-d76a1ab0beda/internal/btree_gc_average_duration_ms:45293 >> /sys/fs/bcache/31c945a7-d96c-499b-945c-d76a1ab0beda/internal/btree_gc_average_frequency_sec:286 >> /sys/fs/bcache/31c945a7-d96c-499b-945c-d76a1ab0beda/internal/btree_gc_last_sec:212 >> /sys/fs/bcache/31c945a7-d96c-499b-945c-d76a1ab0beda/internal/btree_gc_max_duration_ms:61986 >> $ more /sys/fs/bcache/31c945a7-d96c-499b-945c-d76a1ab0beda/internal/btree_nodes >> 5876 >> >> However, fio directly on the SSD device itself shows pretty good performance: >> >> Read IOPS 14,100 (110MiB/s) >> Write IOPS 42,200 (330MiB/s) >> Latency: 106.64 microseconds >> >> Can you shed some light on why CG takes so long (avg 45 seconds) given >> the SSD speed? And is there any way or setting to reduce the CG time >> or lower the GC frequency? >> >> One interesting thing we observed is when the SSD is encrypted via >> dm-crypt, the GC time is shortened ~80% to be under 10 seconds. Is it >> possible that GC writes the blocks one-by-one synchronously, and >> dm-crypt's internal queuing and buffering mitigates the GC IO latency? > > Hi Robert, > > Can I know In which kernel version did you test the patch? > Sorry I missed a bit more information here. > I do a patch rebase and apply it on Linux v6.9. With a 4TB SSD as cache device, I didn’t observe obvious performance advantage of this patch. When I didn’t see obvious performance advantage, the testing was on a 512G Intel Optane memory (with pmem driver) as cache device. > And occasionally I a bit more GC time. It might be from my rebase modification in bch_btree_gc_finish(), And for the above situation, it was on a 4TB NVMe SSD. I guess maybe it was from my improper patch rebase. Once Dongsheng posts a new version for the latest upstream kernel bcache code, I will test the patch again. Thanks. Coly Li
