From: asmadeus@codewreck.org
To: Pierre Barre <pierre@barre.sh>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
v9fs@lists.linux.dev, ericvh@kernel.org, lucho@ionkov.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 9p: Use kvmalloc for message buffers
Date: Thu, 31 Jul 2025 07:07:07 +0900 [thread overview]
Message-ID: <aIqXi6uBaWXtvgm3@codewreck.org> (raw)
In-Reply-To: <bbf2ae2f-d0e6-4f8f-b359-128cd8d5539f@app.fastmail.com>
(Added Willy in To, if you have time to advise on what's appropriate
wrt. memory allocation here to use either as a contiguous virtual memory
buffer or a scatterlist for various kind of dma used by transports
that'd be appreciated)
First - thanks for starting this thread, large contiguous allocations
has been a problem reported regularly in the past, and no-one has had
the energy to address it yet, but it's definitely something worth
tackling.
Pierre Barre wrote on Wed, Jul 30, 2025 at 10:16:13PM +0200:
> As a middle-ground, would it be acceptable to add a transport
> capability flag indicating whether the transport requires contiguous
> memory for DMA?
I think such a flag will be needed even if we do what Christian suggested:
>> So a more reasonable solution instead might be using kvmalloc(), as suggested
>> by you, and adjusting the individual transports such that they translate a
>> virtual memory address to a list of physical addresses via e.g.
>> vmalloc_to_page() if needed.
Start with a requires contiguous flag set for all transports except
trans_fd (I'm not sure about usb, but I'm pretty sure all the rest need
it); then each transport can figure out how to get a scatterlist or
something they need from the allocation, so we don't need to have a big
bang that breaks everything at the same time.
I'm sure virtio's implem will come soon enough, but I don't see anyone
working on RDMA or xen so fast.
> 1. Add a P9_TRANS_REQUIRES_CONTIGUOUS flag to struct p9_trans_module
> 2. Set this flag for virtio, xen, and rdma transports
This is a nit but I'd rather the flag go the other way around, e.g. no
flag means requires contiguous and it's only set after confirming the
transport works
(I just looked at usb and struct usb_request makes me think some drivers
use dma, so, yeah..)
We can always turn it around later if the majority of transports handle
it.
> 3. Modify p9_fcall_init to check the flag:
> if (c->trans_mod->caps & P9_TRANS_REQUIRES_CONTIGUOUS)
> fc->sdata = kmalloc(alloc_msize, GFP_NOFS);
> else
> fc->sdata = kvmalloc(alloc_msize, GFP_NOFS);
I'm also curious if there's something more appropriate than kvmalloc wrt
using either as a contiguous virtual memory buffer or a scatterlist, but
I think this is fine for now unless someone knows of something more
appropriate.
Thanks,
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-07-30 22:17 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 [this message]
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
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=aIqXi6uBaWXtvgm3@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox