From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>, Kanchan Joshi <joshi.k@samsung.com>
Cc: kbusch@kernel.org, io-uring@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
gost.dev@samsung.com
Subject: Re: [PATCH for-next v10 5/7] block: factor out bio_map_get helper
Date: Wed, 28 Sep 2022 11:53:57 -0600 [thread overview]
Message-ID: <40eb2cae-ea17-e1f8-c2f0-2d747ba05c91@kernel.dk> (raw)
In-Reply-To: <6ffd1719-e7c2-420f-1f9e-0b6d16540b46@kernel.dk>
On 9/28/22 11:49 AM, Jens Axboe wrote:
>> Not really new in this code but a question to Jens: The existing
>> bio_map_user_iov has no real upper bounds on the number of bios
>> allocated, how does that fit with the very limited pool size of
>> fs_bio_set?
>
> Good question - I think we'd need to ensure that once we get
> past the initial alloc that we clear any gfp flags that'd make
> the mempool_alloc() wait for completions.
Either that, or just have the passthrough code use non-waiting flags to
begin with. Not guaranteeing forward progress is a bit iffy though...
But in practice it'd be no different than getting a failure due to OOM
because the application submitted a big request and we needed to alloc
and map multiple bios.
--
Jens Axboe
next prev parent reply other threads:[~2022-09-28 17:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220927174622epcas5p1685c0f97a7ee2ee13ba25f5fb58dff00@epcas5p1.samsung.com>
2022-09-27 17:36 ` [PATCH for-next v10 0/7] Fixed-buffer for uring-cmd/passthru Kanchan Joshi
2022-09-27 17:36 ` [PATCH for-next v10 1/7] io_uring: add io_uring_cmd_import_fixed Kanchan Joshi
2022-09-27 17:36 ` [PATCH for-next v10 2/7] io_uring: introduce fixed buffer support for io_uring_cmd Kanchan Joshi
2022-09-27 17:36 ` [PATCH for-next v10 3/7] nvme: refactor nvme_add_user_metadata Kanchan Joshi
2022-09-28 17:18 ` Christoph Hellwig
2022-09-29 11:28 ` Anuj Gupta
2022-09-27 17:36 ` [PATCH for-next v10 4/7] nvme: refactor nvme_alloc_request Kanchan Joshi
2022-09-28 17:19 ` Christoph Hellwig
2022-09-29 11:30 ` Anuj Gupta
2022-09-27 17:36 ` [PATCH for-next v10 5/7] block: factor out bio_map_get helper Kanchan Joshi
2022-09-28 17:31 ` Christoph Hellwig
2022-09-28 17:49 ` Jens Axboe
2022-09-28 17:53 ` Jens Axboe [this message]
2022-09-29 11:34 ` Anuj Gupta
2022-09-27 17:36 ` [PATCH for-next v10 6/7] block: extend functionality to map bvec iterator Kanchan Joshi
2022-09-28 17:40 ` Christoph Hellwig
2022-09-29 11:33 ` Anuj Gupta
2022-09-27 17:36 ` [PATCH for-next v10 7/7] nvme: wire up fixed buffer support for nvme passthrough Kanchan Joshi
2022-09-28 17:59 ` Christoph Hellwig
2022-09-29 11:36 ` Anuj Gupta
2022-09-28 14:28 ` [PATCH for-next v10 0/7] Fixed-buffer for uring-cmd/passthru Jens Axboe
2022-09-28 17:12 ` Christoph Hellwig
2022-09-28 17:13 ` Jens Axboe
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=40eb2cae-ea17-e1f8-c2f0-2d747ba05c91@kernel.dk \
--to=axboe@kernel.dk \
--cc=gost.dev@samsung.com \
--cc=hch@lst.de \
--cc=io-uring@vger.kernel.org \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--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.