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 <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
