From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756771AbdKDOSg (ORCPT ); Sat, 4 Nov 2017 10:18:36 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:52249 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756720AbdKDOSe (ORCPT ); Sat, 4 Nov 2017 10:18:34 -0400 X-Google-Smtp-Source: ABhQp+RY52y61N9VkPbD4SL+C2FR4EPsYDFRXkmtm7yE54Tt8ZzrU7GiWJ9CBGH/dbNDtr9guLrMQQ== Subject: Re: [PATCH V3 0/7] blk-mq: don't allocate driver tag beforehand for flush rq To: Ming Lei , linux-block@vger.kernel.org, Christoph Hellwig Cc: Omar Sandoval , Bart Van Assche , Hannes Reinecke , linux-kernel@vger.kernel.org References: <20171102152438.25324-1-ming.lei@redhat.com> <20171104041703.GA2819@ming.t460p> From: Jens Axboe Message-ID: <016e4ab3-c5db-9871-0e4d-cd3ff31eee22@kernel.dk> Date: Sat, 4 Nov 2017 08:18:29 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171104041703.GA2819@ming.t460p> 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 11/03/2017 10:17 PM, Ming Lei wrote: > On Thu, Nov 02, 2017 at 11:24:31PM +0800, Ming Lei wrote: >> Hi Jens, >> >> This patchset avoids to allocate driver tag beforehand for flush rq >> in case of I/O scheduler, then flush rq isn't treated specially >> wrt. get/put driver tag, code gets cleanup much, such as, >> reorder_tags_to_front() is removed, and we needn't to worry >> about request order in dispatch list for avoiding I/O deadlock. >> >> 'dbench -t 30 -s 64' has been run on different devices(shared tag, >> multi-queue, singele queue, ...), and no issues are observed, >> even very low queue depth test are run, debench still works well. >> >> Please consider it for V4.15, thanks! > > Hi Jens, > > As we discussed before, this patch is a good cleanup on handling flush > request, could you share your opinion on V3? It looks fine to me. But I'd really like to have the potential hang in the current 4.15 branch ironed out, before we pile more stuff on top. Meanwhile, I'll see if this passes my testing. -- Jens Axboe