From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: axboe@kernel.dk, hch@lst.de, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org, sagi@grimberg.me,
asml.silence@gmail.com, anuj20.g@samsung.com,
joshi.k@samsung.com, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv14 10/11] nvme: register fdp parameters with the block layer
Date: Mon, 16 Dec 2024 17:12:55 +0100 [thread overview]
Message-ID: <20241216161255.GC24735@lst.de> (raw)
In-Reply-To: <20241211183514.64070-11-kbusch@meta.com>
On Wed, Dec 11, 2024 at 10:35:13AM -0800, Keith Busch wrote:
> + size = le32_to_cpu(hdr.sze);
> + if (size > PAGE_SIZE * MAX_ORDER_NR_PAGES) {
> + dev_warn(ctrl->device, "FDP config size too large:%zu\n",
> + size);
> + return 0;
> + h = vmalloc(size);
> + if (!h)
> + return -ENOMEM;
Isn't an unconditional vmalloc here for something that usually should
have less than a handful of descriptors a little aggressive? I'd use
kvmalloc here to get the best of both worlds, and the free path seems
to already use kvfree anyway.
Otherwise the incremental changes vs the previous version for the entire
series look good to me.
next prev parent reply other threads:[~2024-12-16 16:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20241211190851epcas5p2a359c12000fc73df8920e4801563504c@epcas5p2.samsung.com>
2024-12-11 18:35 ` [PATCHv14 00/11] block write streams with nvme fdp Keith Busch
2024-12-11 18:35 ` [PATCHv14 10/11] nvme: register fdp parameters with the block layer Keith Busch
2024-12-12 13:14 ` Hannes Reinecke
[not found] ` <CGME20241213060117epcas5p33e93030b04f8d51f0367d375faa2adaf@epcas5p3.samsung.com>
2024-12-13 5:53 ` Nitesh Shetty
2024-12-16 16:12 ` Christoph Hellwig [this message]
2024-12-12 11:39 ` [PATCHv14 00/11] block write streams with nvme fdp Kanchan Joshi
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=20241216161255.GC24735@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox