From: asmadeus <asmadeus@codewreck.org>
To: Pierre Barre <pierre@barre.sh>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
v9fs@lists.linux.dev, ericvh@kernel.org, lucho@ionkov.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] 9p: Use kvmalloc for message buffers on supported transports
Date: Mon, 3 Nov 2025 16:52:53 +0900 [thread overview]
Message-ID: <aQhfVa_jdI_1kQwB@codewreck.org> (raw)
In-Reply-To: <d2017c29-11fb-44a5-bd0f-4204329bbefb@app.fastmail.com>
Pierre Barre wrote on Thu, Oct 16, 2025 at 03:58:36PM +0200:
> While developing a 9P server (https://github.com/Barre/ZeroFS) and
> testing it under high-load, I was running into allocation failures.
> The failures occur even with plenty of free memory available because
> kmalloc requires contiguous physical memory.
>
> This results in errors like:
> ls: page allocation failure: order:7, mode:0x40c40(GFP_NOFS|__GFP_COMP)
>
> This patch introduces a transport capability flag (supports_vmalloc)
> that indicates whether a transport can work with vmalloc'd buffers
> (non-physically contiguous memory). Transports requiring DMA should
> leave this flag as false.
>
> The fd-based transports (tcp, unix, fd) set this flag to true, and
> p9_fcall_init will use kvmalloc instead of kmalloc for these
> transports. This allows the allocator to fall back to vmalloc when
> contiguous physical memory is not available.
>
> Additionally, if kmem_cache_alloc fails, the code falls back to
> kvmalloc for transports that support it.
>
> Signed-off-by: Pierre Barre <pierre@barre.sh>
Thanks, it's now picked up and queued in -next -- will send to Linus in
a couple of months.
FWIW, I prefer (and I think it's the norm in the linux world) if patches
new versions aren't sent as a reply to previous version, it confuses
tools like b4 that fetch the patch thread for version operations.
If you send patches again please just send later versions without
using --in-reply-to :)
Cheers,
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-11-03 7:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 15:08 [PATCH] 9p: Use kvmalloc for message buffers Pierre Barre
2025-07-30 16:08 ` Christian Schoenebeck
2025-07-30 16:19 ` Pierre Barre
2025-07-30 17:28 ` Christian Schoenebeck
2025-07-30 20:16 ` Pierre Barre
2025-07-30 22:07 ` asmadeus
2025-07-31 0:36 ` Pierre Barre
2025-08-06 15:50 ` Pierre Barre
2025-08-06 21:44 ` Dominique Martinet
2025-08-08 11:12 ` Christian Schoenebeck
2025-10-16 7:01 ` [PATCH v2] 9p: Use kvmalloc for message buffers on supported transports Pierre Barre
2025-10-16 7:26 ` Dominique Martinet
2025-10-16 13:06 ` Christian Schoenebeck
2025-10-16 13:58 ` [PATCH v3] " Pierre Barre
2025-10-17 5:49 ` Christophe JAILLET
2025-11-03 7:52 ` asmadeus [this message]
2025-11-03 10:16 ` Pierre Barre
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=aQhfVa_jdI_1kQwB@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=pierre@barre.sh \
--cc=v9fs@lists.linux.dev \
--cc=willy@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.