From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756104AbeASP0S (ORCPT ); Fri, 19 Jan 2018 10:26:18 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:46786 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756072AbeASPZq (ORCPT ); Fri, 19 Jan 2018 10:25:46 -0500 X-Google-Smtp-Source: ACJfBouHQAW4qKUGNb/o0Uq4eTjBu+v/3XyZPPC+Ae8xP2cPIQQkFBjlgzcBroB81uzLBzTuYGtuHg== Subject: Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle To: Bart Van Assche , "ming.lei@redhat.com" Cc: "dm-devel@redhat.com" , "hch@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "osandov@fb.com" , "snitzer@redhat.com" References: <20180118024124.8079-1-ming.lei@redhat.com> <20180118170353.GB19734@redhat.com> <1516296056.2676.23.camel@wdc.com> <20180118183039.GA20121@redhat.com> <1516301278.2676.35.camel@wdc.com> <20180119023212.GA25413@ming.t460p> <20180119072623.GB25369@ming.t460p> <1516375212.3190.4.camel@wdc.com> From: Jens Axboe Message-ID: <96ec5bc4-fe4c-4ac7-9bec-ee483a1c5b90@kernel.dk> Date: Fri, 19 Jan 2018 08:25:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 MIME-Version: 1.0 In-Reply-To: <1516375212.3190.4.camel@wdc.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/19/18 8:20 AM, Bart Van Assche wrote: > On Fri, 2018-01-19 at 15:26 +0800, Ming Lei wrote: >> Please see queue_delayed_work_on(), hctx->run_work is shared by all >> scheduling, once blk_mq_delay_run_hw_queue(100ms) returns, no new >> scheduling can make progress during the 100ms. > > How about addressing that as follows: > > diff --git a/block/blk-mq.c b/block/blk-mq.c > index f7515dd95a36..57f8379a476d 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -1403,9 +1403,9 @@ static void __blk_mq_delay_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async, > put_cpu(); > } > > - kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx), > - &hctx->run_work, > - msecs_to_jiffies(msecs)); > + kblockd_mod_delayed_work_on(blk_mq_hctx_next_cpu(hctx), > + &hctx->run_work, > + msecs_to_jiffies(msecs)); > } Exactly. That's why I said it was just a bug in my previous email, not honoring a newer run is just stupid. Only other thing you have to be careful with here is the STOPPED bit. -- Jens Axboe