From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug() Date: Fri, 11 Sep 2015 16:36:39 -0700 Message-ID: References: <20150911193747.GA4150@ret.masoncoding.com> <55F33C2B.1010508@fb.com> <20150911231636.GC4150@ret.masoncoding.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 To: Chris Mason , Linus Torvalds , Josef Bacik , LKML , linux-fsdevel , Dave Chinner , Neil Brown , Jan Kara , Christoph Hellwig Return-path: In-Reply-To: <20150911231636.GC4150@ret.masoncoding.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Sep 11, 2015 at 4:16 PM, Chris Mason wrote: > > For 4.3 timeframes, what runs do you want to see numbers for: > > 1) revert > 2) my hack > 3) plug over multiple sbs (on different devices) > 4) ? Just 2 or 3. I don't think the plain revert is all that interesting, and I think the "anything else" is far too late for this merge window. So we'll go with either (2) your patch (which I obviously don't _like_, but apart from the ugliness I don't think there's anything technically wrong with), or with (3) the "plug across a bigger area". So the only issue with (3) is whether that's just "revert plus the patch I sent out", or whether we should unplug/replug over the "wait synchronously for an inode" case (iow, the "inode_sleep_on_writeback()"). The existing plug code (that has the spinlock issue) already has a "wait on inode" case, and did *not* unplug over that call, but broadening the plugging further now ends up having two of those "wait synchronosly on inode". 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. Linus