Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH V11 0/4] blk-mq: refactor code of issue directly
To:     Jianchao Wang <jianchao.w.wang@oracle.com>
Cc:     ming.lei@redhat.com, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <1544152185-32667-1-git-send-email-jianchao.w.wang@oracle.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <b2bcbb76-af6f-7660-2bc3-9796338cccff@kernel.dk>
Date:   Thu, 6 Dec 2018 20:16:20 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <1544152185-32667-1-git-send-email-jianchao.w.wang@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 12/6/18 8:09 PM, Jianchao Wang wrote:
> Hi Jens
> 
> Please consider this patchset for 4.21.
> 
> It refactors the code of issue request directly to unify the interface
> and make the code clearer and more readable.
> 
> This patch set is rebased on the recent for-4.21/block and add the 1st
> patch which inserts the non-read-write request to hctx dispatch
> list to avoid to involve merge and io scheduler when bypass_insert
> is true, otherwise, inserting is ignored, BLK_STS_RESOURCE is returned
> and the caller will fail forever.
> 
> The 2nd patch refactors the code of issue request directly to unify the
> helper interface which could handle all the cases.
> 
> The 3rd patch make blk_mq_sched_insert_requests issue requests directly
> with 'bypass' false, then it needn't to handle the non-issued requests
> any more.
> 
> The 4th patch replace and kill the blk_mq_request_issue_directly.

Sorry to keep iterating on this, but let's default to inserting to
the dispatch list if we ever see busy from a direct dispatch. I'm fine
with doing that for 4.21, as suggested by Ming, I just didn't want to
fiddle with it for 4.20. This will prevent any merging on the request
going forward, which I think is a much safer default.

You do this already for some cases. Let's do it unconditionally for
a request that was ever subjected to ->queue_rq() and we didn't either
error or finish after the fact.

-- 
Jens Axboe