From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755362AbbKCRSd (ORCPT ); Tue, 3 Nov 2015 12:18:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45033 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754792AbbKCRSR (ORCPT ); Tue, 3 Nov 2015 12:18:17 -0500 From: Jeff Moyer To: Jens Axboe Cc: Jan Kara , LKML Subject: Re: Flush requests not going through IO scheduler References: <20151102122009.GE13433@quack.suse.cz> <56379619.4020805@kernel.dk> <20151103164128.GF4063@quack.suse.cz> <5638E597.4090109@kernel.dk> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Tue, 03 Nov 2015 12:18:12 -0500 In-Reply-To: <5638E597.4090109@kernel.dk> (Jens Axboe's message of "Tue, 3 Nov 2015 09:49:27 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jens Axboe writes: >>> Certainly, the current behavior is undoubtedly broken. The least >>> intrusive fix would be to kick off scheduling when we add it to the >>> request, but the elevator should handle it. Are you going to be up >>> for hacking up a fix? >> >> I have some trouble understanding what do you mean exactly. Do you think we >> should just call __blk_run_queue() after we add the request to >> q->queue_head? > > No, that won't be enough, as it won't always break out of the idle > logic. We need to ensure that the new request is noticed, so that CFQ > knows and can decide to kick off things. Hmm? __blk_run_queue calls the request_fn, which will call blk_peek_request, which calls __elv_next_request, which will find the request on queue_head. Right? while (1) { if (!list_empty(&q->queue_head)) { rq = list_entry_rq(q->queue_head.next); return rq; Cheers, Jeff