From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753922AbbIROX7 (ORCPT ); Fri, 18 Sep 2015 10:23:59 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:57539 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751068AbbIROX5 (ORCPT ); Fri, 18 Sep 2015 10:23:57 -0400 Subject: Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug() To: Chris Mason , Linus Torvalds , Dave Chinner , Jan Kara , Josef Bacik , LKML , linux-fsdevel , Neil Brown , Christoph Hellwig , Tejun Heo References: <20150917021453.GO3902@dastard> <20150917224230.GF8624@ret.masoncoding.com> <20150917235647.GG8624@ret.masoncoding.com> <20150918003735.GR3902@dastard> <20150918054044.GT3902@dastard> <20150918131615.GI8624@ret.masoncoding.com> From: Jens Axboe Message-ID: <55FC1E72.3040500@fb.com> Date: Fri, 18 Sep 2015 08:23:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150918131615.GI8624@ret.masoncoding.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-09-10_07:2015-09-09,2015-09-10,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/18/2015 07:16 AM, Chris Mason wrote: > On Thu, Sep 17, 2015 at 11:04:03PM -0700, Linus Torvalds wrote: >> On Thu, Sep 17, 2015 at 10:40 PM, Dave Chinner wrote: >>> >>> Ok, makes sense - the plug is not being flushed as we switch away, >>> but Chris' patch makes it do that. >> >> Yup. > > Huh, that does make much more sense, thanks Linus. I'm wondering where > else I've assumed that cond_resched() unplugged. > >> >> And I actually think Chris' patch is better than the one I sent out >> (but maybe the scheduler people should take a look at the behavior of >> cond_resched()), I just wanted you to test that to verify the >> behavior. It makes no sense for preemption schedule to NOT unplug, the fact that it doesn't is news to me as well. It was never the intent of the unplug-on-schedule to NOT unplug for certain schedule out events, that seems like very odd behavior. -- Jens Axboe