[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <42356AE9-D6F7-425C-BCAE-8DB19A7E0629@barre.sh>
Date: Mon, 3 Nov 2025 11:16:51 +0100
From: Pierre Barre <pierre@...re.sh>
To: asmadeus <asmadeus@...ewreck.org>
Cc: Christian Schoenebeck <linux_oss@...debyte.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
v9fs@...ts.linux.dev,
ericvh@...nel.org,
lucho@...kov.net,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] 9p: Use kvmalloc for message buffers on supported
transports
> On 3 Nov 2025, at 08:52, asmadeus <asmadeus@...ewreck.org> wrote:
>
> 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@...re.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 :)
Got it, thank you!
Best,
Pierre
>
> Cheers,
> --
> Dominique Martinet | Asmadeus
Powered by blists - more mailing lists