Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH v3 2/3] blk-mq: Freeze and quiesce all queues for
 tagset in elevator_exit()
To:     Ming Lei <ming.lei@redhat.com>
CC:     <hare@suse.de>, <bvanassche@acm.org>, <axboe@kernel.dk>,
        <hch@lst.de>, <linux-block@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <pragalla@codeaurora.org>,
        <kashyap.desai@broadcom.com>, <yuyufen@huawei.com>
References: <1614957294-188540-1-git-send-email-john.garry@huawei.com>
 <1614957294-188540-3-git-send-email-john.garry@huawei.com>
 <YElrSFGyim3rjDN+@T590>
From:   John Garry <john.garry@huawei.com>
Message-ID: <8c6c6783-6152-2332-2f50-14c409e40320@huawei.com>
Date:   Thu, 11 Mar 2021 08:21:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <YElrSFGyim3rjDN+@T590>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/03/2021 00:58, Ming Lei wrote:
>> Indeed, blk_mq_queue_tag_busy_iter() already does take a reference to its
>> queue usage counter when called, and the queue cannot be frozen to switch
>> IO scheduler until all refs are dropped. This ensures no stale references
>> to IO scheduler requests will be seen by blk_mq_queue_tag_busy_iter().
>>
>> However, there is nothing to stop blk_mq_queue_tag_busy_iter() being
>> run for another queue associated with the same tagset, and it seeing
>> a stale IO scheduler request from the other queue after they are freed.
>>
>> To stop this happening, freeze and quiesce all queues associated with the
>> tagset as the elevator is exited.
> I think this way can't be accepted since switching one queue's scheduler
> is nothing to do with other request queues attached to same HBA.
> 
> This patch will cause performance regression because userspace may
> switch scheduler according to medium or workloads, at that time other
> LUNs will be affected by this patch.

Hmmm..that was my concern also. Do you think that it may cause a big 
impact? Depends totally on the workload, I suppose.

FWIW, it is useful though for solving both iterator problems.

Thanks,
John