On Mon, Aug 19, 2013 at 12:09:24AM +0200, Stefan Priebe wrote: > > Vanilla 3.10.7 + bcache: Fix a writeback performance regression > > http://pastebin.com/raw.php?i=LXZk4cMH Whoops, at first I thought this was the same bug as one I'd already been chasing down that had been a harmless bug - turns out I didn't look closely enough at the backtrace. What happened is background writeback is deadlocking, because for some reason the workqueue it's running out of is a singlethreaded workqueue, so as soon as it decides to queue enough writeback bios that it has to sleep on that semaphore (which often won't happen due to the PD controller based ratelimiting) - boom, deadlock. Here's the fixup patch I just tested and am applying: >From 0af68de350e05e43fd093b36dcb0fe8aa838fabf Mon Sep 17 00:00:00 2001 From: Kent Overstreet <kmo@xxxxxxxxxxxxx> Date: Mon, 19 Aug 2013 15:26:22 -0700 Subject: [PATCH] bcache: Fix a writeback deadlock Signed-off-by: Kent Overstreet <kmo@xxxxxxxxxxxxx> diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c index f88c62e..27ac519 100644 --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -351,7 +351,7 @@ static void write_dirty(struct closure *cl) closure_bio_submit(&io->bio, cl, &io->dc->disk); - continue_at(cl, write_dirty_finish, dirty_wq); + continue_at(cl, write_dirty_finish, system_wq); } static void read_dirty_endio(struct bio *bio, int error) @@ -371,7 +371,7 @@ static void read_dirty_submit(struct closure *cl) closure_bio_submit(&io->bio, cl, &io->dc->disk); - continue_at(cl, write_dirty, dirty_wq); + continue_at(cl, write_dirty, system_wq); } static void read_dirty(struct closure *cl) @@ -512,7 +512,7 @@ void bch_writeback_exit(void) int __init bch_writeback_init(void) { - dirty_wq = create_singlethread_workqueue("bcache_writeback"); + dirty_wq = create_workqueue("bcache_writeback"); if (!dirty_wq) return -ENOMEM; -- 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
