On 29/01/2018 7:58 PM, tang.junhui@xxxxxxxxxx wrote: > From: Tang Junhui <tang.junhui@xxxxxxxxxx> > > In GC thread, we record the latest GC key in gc_done, which is expected > to be used for incremental GC, but in currently code, we didn't realize > it. When GC runs, front side IO would be blocked until the GC over, it > would be a long time if there is a lot of btree nodes. > > This patch realizes incremental GC, the main ideal is that, when there > are front side I/Os, after GC some nodes (100), we stop GC, release locker > of the btree node, and go to process the front side I/Os for some times > (100 ms), then go back to GC again. > > By this patch, when we doing GC, I/Os are not blocked all the time, and > there is no obvious I/Os zero jump problem any more. > > Signed-off-by: Tang Junhui <tang.junhui@xxxxxxxxxx> Hi Junhui, It sounds great :-) Currently I am not very familiar with gc code, I need some time to understand how bcache GC works before providing my feedback. Please give me some time, I hope I am able to provide my comment after Chinese Spring Festival. Hope other people may have a look before I am able to. Thanks. Coly Li [code snip] -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
