From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Keith Busch <kbusch@meta.com>,
linux-nvme@lists.infradead.org, hch@lst.de
Cc: Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 1/2] nvme-pci: fix freeing single sgl
Date: Mon, 13 Feb 2023 15:01:26 +0100 [thread overview]
Message-ID: <dae83fe07efc8fa227ea3bba5f419488df392eaa.camel@linux.ibm.com> (raw)
In-Reply-To: <20230210180347.3613573-1-kbusch@meta.com>
On Fri, 2023-02-10 at 10:03 -0800, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> There may only be a single DMA mapped entry from multiple physical
> segments, which means we don't allocate a separte SGL list. Check the
> number of allocations prior to know if we need to free something.
>
> Freeing a single list allocation is the same for both PRP and SGL
> usages, so we don't need to check the use_sgl flag anymore.
>
> Fixes: 01df742d8c5c0 ("nvme-pci: remove SGL segment descriptors")
> Reported-by: Niklas Schnelle <schnelle@linux.ibm.com>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
> Niklas,
> This is a little different than the one you tested, so I didn't include
> your "Tested-by". I'm confident this is patch still fixes the issue,
> though.
>
> drivers/nvme/host/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index a331fbfa9a667..47d6b0023e3a8 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -556,7 +556,7 @@ static void nvme_unmap_data(struct nvme_dev *dev, struct request *req)
> if (iod->nr_allocations == 0)
> dma_pool_free(dev->prp_small_pool, iod->list[0].sg_list,
> iod->first_dma);
> - else if (iod->use_sgl)
> + else if (iod->nr_allocations == 1)
> dma_pool_free(dev->prp_page_pool, iod->list[0].sg_list,
> iod->first_dma);
> else
Ah nice that makes it look cleaner and you got rid of the use_sgl flag.
I gave the two new patches a quick test on top of today's linux-next
and they work fine too. In fact while I don't have hard numbers and my
environment is quite noisy and there is of course other changes at play
too but linux-next does seem to get a bit more IOPS than v6.2-rc8 in my
FIO 4k random read test.
Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
prev parent reply other threads:[~2023-02-13 14:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 18:03 [PATCH 1/2] nvme-pci: fix freeing single sgl Keith Busch
2023-02-10 18:03 ` [PATCH 2/2] nvme-pci: remove iod use_sgls Keith Busch
2023-02-13 6:12 ` [PATCH 1/2] nvme-pci: fix freeing single sgl Christoph Hellwig
2023-02-13 14:01 ` Niklas Schnelle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dae83fe07efc8fa227ea3bba5f419488df392eaa.camel@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-nvme@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.