bcache: call force_wake_up_gc() if necessary in check_should_bypass()
authorColy Li <colyli@suse.de>
Tue, 28 May 2024 12:09:13 +0000 (20:09 +0800)
committerJens Axboe <axboe@kernel.dk>
Tue, 28 May 2024 12:55:59 +0000 (06:55 -0600)
commit05356938a4be356adde4eab4425c6822f3c7d706
tree8ea28fce9cf559125baab9f7083f1f8be58e545a
parenta14a68b76954e73031ca6399abace17dcb77c17a
bcache: call force_wake_up_gc() if necessary in check_should_bypass()

If there are extreme heavy write I/O continuously hit on relative small
cache device (512GB in my testing), it is possible to make counter
c->gc_stats.in_use continue to increase and exceed CUTOFF_CACHE_ADD.

If 'c->gc_stats.in_use > CUTOFF_CACHE_ADD' happens, all following write
requests will bypass the cache device because check_should_bypass()
returns 'true'. Because all writes bypass the cache device, counter
c->sectors_to_gc has no chance to be negative value, and garbage
collection thread won't be waken up even the whole cache becomes clean
after writeback accomplished. The aftermath is that all write I/Os go
directly into backing device even the cache device is clean.

To avoid the above situation, this patch uses a quite conservative way
to fix: if 'c->gc_stats.in_use > CUTOFF_CACHE_ADD' happens, only wakes
up garbage collection thread when the whole cache device is clean.

Before the fix, the writes-always-bypass situation happens after 10+
hours write I/O pressure on 512GB Intel optane memory which acts as
cache device. After this fix, such situation doesn't happen after 36+
hours testing.

Signed-off-by: Coly Li <colyli@suse.de>
Link: https://lore.kernel.org/r/20240528120914.28705-3-colyli@suse.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
drivers/md/bcache/request.c