[PATCH V2] nvme: don't wait freeze during resetting
Ming Lei
ming.lei at redhat.com
Mon Oct 17 23:29:04 PDT 2022
On Mon, Oct 10, 2022 at 10:25:33AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 26, 2022 at 09:34:04AM +0800, Ming Lei wrote:
> > First it isn't necessary to call nvme_wait_freeze during reset.
> > For nvme-pci, if tagset isn't allocated, there can't be any inflight
> > IOs; otherwise blk_mq_update_nr_hw_queues can freeze & wait queues.
> >
> > Second, since commit bdd6316094e0 ("block: Allow unfreezing of a queue
> > while requests are in progress"), it is fine to unfreeze queue without
> > draining inflight IOs.
> >
> > Reviewed-by: Sagi Grimberg <sagi at grimberg.me>
> > Reviewed-by: Chao Leng <lengchao at huawei.com>
> > Reviewed-by: Keith Busch <kbusch at kernel.org>
> > Signed-off-by: Ming Lei <ming.lei at redhat.com>
> > ---
> > V2:
> > - remove the change in rdma/tcp which may make non-mpath reset
> > time much longer, as pointed by Sagi
>
> So how can this be corret for PCI and apple but not for rdma and TCP?
It doesn't mean it isn't correct for rdma and TCP, just the similar
patch may increase timeout delay a lot for the two, nvme_wait_freeze_timeout(ctrl,
NVME_IO_TIMEOUT) waits 30 secs at default, but nvme_wait_freeze() may wait
much longer if retry is involved.
>
> Also please don't update two drivers in a single patch.
But the change is same for both two, and we have lots of such example,
same change on lots of subsystem.
thanks,
Ming
More information about the Linux-nvme
mailing list