From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug() Date: Fri, 11 Sep 2015 22:15:29 -0400 Message-ID: <20150912021529.GD4150@ret.masoncoding.com> References: <20150911193747.GA4150@ret.masoncoding.com> <55F33C2B.1010508@fb.com> <20150911231636.GC4150@ret.masoncoding.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Josef Bacik , LKML , linux-fsdevel , Dave Chinner , Neil Brown , Jan Kara , Christoph Hellwig To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Sep 11, 2015 at 05:52:27PM -0700, Linus Torvalds wrote: > On Fri, Sep 11, 2015 at 4:36 PM, Linus Torvalds > wrote: > > > > Are we really ok with waiting synchronously for an inode while holding > > the plug? No chance of deadlock (waiting for IO that we've plugged)? > > That issue is true even of the current code, though, and I have _not_ > > really thought that through, it's just a worry. > > Never mind. We still flush the plug on explicit scheduling events. I > wonder why I thought we got rid of that. Some kind of "senior moment", But flushing on schedule is a little different. It ends up calling blk_schedule_flush_plug() which will hand off work to kblockd through blk_run_queue_async() Not a huge deal, but if we're scheduling to wait for that IO, we should really run the plug ourselves so that we're not waiting for kblockd too. -chris