From: Gabriel Krisman Bertazi <gabriel@krisman.be>
To: David Wei <dw@davidwei.uk>, io-uring@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>, Pavel Begunkov <asml.silence@gmail.com>
Subject: Re: [PATCH] io_uring/memmap: fix non-compound alloc fallback with memcg accounting
Date: Thu, 01 Oct 2026 14:55:00 -0400 [thread overview]
Message-ID: <87h5j5w8sb.fsf@mailhost.krisman.be> (raw)
In-Reply-To: <20261001181752.537767-1-dw@davidwei.uk>
David Wei <dw@davidwei.uk> writes:
> io_region_allocate_pages() first tries io_mem_alloc_compound(). If that
> fails, it uses alloc_pages_bulk_node() to allocate separate pages.
>
> The bulk allocator does not support memcg accounting. __GFP_ACCOUNT is
> unconditionally supplied, so when memcg_kmem_online() is true, it only
> allocates one page. For a multi-page request, io_uring treats this short
> result as failure and returns ENOMEM, even when the memcg has enough
> space for all pages.
>
> When this happens, fill the rest of the request with order 0 allocations
> via alloc_page(), which support memcg accounting. This maintains the
> existing fast path, while fixing the incorrect ENOMEM return when memcg
> is used.
>
> Signed-off-by: David Wei <dw@davidwei.uk>
> ---
> io_uring/memmap.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/io_uring/memmap.c b/io_uring/memmap.c
> index cb3db32e8255..cc8ac129a0c7 100644
> --- a/io_uring/memmap.c
> +++ b/io_uring/memmap.c
> @@ -183,6 +183,7 @@ static int io_region_allocate_pages(struct io_mapped_region *mr,
> size_t size = io_region_size(mr);
> unsigned long nr_allocated;
> struct page **pages;
> + struct page *page;
>
> pages = kvmalloc_objs(*pages, mr->nr_pages, gfp);
> if (!pages)
> @@ -195,6 +196,13 @@ static int io_region_allocate_pages(struct io_mapped_region *mr,
>
> nr_allocated = alloc_pages_bulk_node(gfp, NUMA_NO_NODE,
> mr->nr_pages, pages);
> + while (nr_allocated < mr->nr_pages) {
> + page = alloc_page(gfp);
> + if (!page)
> + break;
> +
> + pages[nr_allocated++] = page;
> + }
FWIW, I looked at this recently and really think this should be the
alloc_pages_bulk_/kmem_alloc_bulk* actual semantics. But that is a
bigger sell and I only found io_uring would actually benefit from it.
Feel free to add:
Reviewed-by: Gabriel Krisman Bertazi <krisman@suse.de>
Perhaps also
Fixes: 1e21df691ffa ("io_uring/memmap: implement kernel allocated regions")
> if (nr_allocated != mr->nr_pages) {
> if (nr_allocated)
> release_pages(pages, nr_allocated);
> --
> 2.53.0-Meta
>
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2026-10-01 18:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 18:17 [PATCH] io_uring/memmap: fix non-compound alloc fallback with memcg accounting David Wei
2026-10-01 18:55 ` Gabriel Krisman Bertazi [this message]
2026-10-01 19:59 ` David Wei
2026-10-02 14:58 ` 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=87h5j5w8sb.fsf@mailhost.krisman.be \
--to=gabriel@krisman.be \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=dw@davidwei.uk \
--cc=io-uring@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox