Stephen R. van den Berg wrote:
>What I notice are:
>- The 100% CPU usage for four bcache_writebac processes is back. I've
> already tried raising the value you suggested from 30 to 60, but I did
> not have an opportunity to reboot yet. Will report back on this.
What I saw:
a. After running several hours, copying roughly 3.0TB through the two
SSD caching devices onto the BTRFS backing device consisting of
four HDDs, the bcache_writebac processes were still eating 100% CPU each.
b. Then did a manual umount of the fs, then stopped the bcache device
through the proc filesystem.
c. Rebooted.
d. Came back in a patched kernel, 100% CPU usage is gone.
The patch I used (I did not investigate the correctness of the value
picked, I simply doubled it as an initial guess):
commit 2abecdbd214c94741012de32759bb0de4c6adbf9
Author: Stephen R. van den Berg <srb@xxxxxxx>
Date: Tue Jan 13 23:24:52 2015 +0100
Increase btree_scan_ratelimit to avoid 100% CPU hogging.
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 653419b..5fff8ad 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -867,7 +867,7 @@ static struct cache_set *bch_cache_set_alloc(struct cache *ca)
c->error_limit = 16 << IO_ERROR_SHIFT;
c->tiering_percent = 10;
- c->btree_scan_ratelimit = 30;
+ c->btree_scan_ratelimit = 60;
c->copy_gc_enabled = 1;
c->tiering_enabled = 1;
--
Stephen.
--
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
