From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754597AbdBPKqo (ORCPT ); Thu, 16 Feb 2017 05:46:44 -0500 Received: from mail-wr0-f170.google.com ([209.85.128.170]:36030 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752925AbdBPKqm (ORCPT ); Thu, 16 Feb 2017 05:46:42 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler From: Paolo Valente In-Reply-To: <1481933536-12844-8-git-send-email-axboe@fb.com> Date: Thu, 16 Feb 2017 11:46:38 +0100 Cc: Jens Axboe , linux-block@vger.kernel.org, Linux-Kernal , osandov@fb.com Message-Id: References: <1481933536-12844-1-git-send-email-axboe@fb.com> <1481933536-12844-8-git-send-email-axboe@fb.com> To: Jens Axboe X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v1GAklB3026353 > Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe ha scritto: > > This is basically identical to deadline-iosched, except it registers > as a MQ capable scheduler. This is still a single queue design. > > Signed-off-by: Jens Axboe ... > + > +static void dd_merged_requests(struct request_queue *q, struct request *req, > + struct request *next) > +{ > + /* > + * if next expires before rq, assign its expire time to rq > + * and move into next position (next will be deleted) in fifo > + */ > + if (!list_empty(&req->queuelist) && !list_empty(&next->queuelist)) { > + if (time_before((unsigned long)next->fifo_time, > + (unsigned long)req->fifo_time)) { > + list_move(&req->queuelist, &next->queuelist); > + req->fifo_time = next->fifo_time; > + } > + } > + Jens, while trying to imagine the possible causes of Bart's hang with bfq-mq, I've bumped into the following doubt: in the above function (in my case, in bfq-mq-'s equivalent of the above function), are we sure that neither req or next could EVER be in dd->dispatch instead of dd->fifo_list? I've tried to verify it, but, although I think it has never happened in my tests, I was not able to make sure that no unlucky combination may ever happen (considering also the use of blk_rq_is_passthrough too, to decide where to put a new request). I'm making a blunder, right? Thanks, Paolo