From: Brendan Jackman <jackmanb@google.com>
To: Vishal Moola <vishal.moola@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<hch@infradead.org>, <urezki@gmail.com>,
<intel-gfx@lists.freedesktop.org>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH 0/2] vmalloc: Introduce vmap_file()
Date: Tue, 08 Apr 2025 14:04:09 +0000 [thread overview]
Message-ID: <D91BB945EKGW.UZSCJRUM034H@google.com> (raw)
In-Reply-To: <CAOzc2pyKFJKxkTs989rMzRaMSwR+EBXDiCB-2xBRTiu=Y8FLvw@mail.gmail.com>
On Mon Feb 3, 2025 at 6:53 PM UTC, Vishal Moola wrote:
> On Thu, Jan 30, 2025 at 4:48 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> On Thu, 30 Jan 2025 16:18:04 -0800 "Vishal Moola (Oracle)" <vishal.moola@gmail.com> wrote:
>>
>> > Currently, users have to call vmap() or vmap_pfn() to map pages to
>> > kernel virtual space. vmap() requires the page references, and
>> > vmap_pfn() requires page pfns. If we have a file but no page references,
>> > we have to do extra work to map them.
>> >
>> > Create a function, vmap_file(), to map a specified range of a given
>> > file to kernel virtual space. Also convert a user that benefits from
>> > vmap_file().
>> >
>>
>> Seems like a pretty specialized thing. Have you identified any other
>> potential users of vmap_file()? I couldn't see any.
>>
>> If drm is likely to remain the only user of this, perhaps we should
>> leave the code down in drivers/gpu/drm for now?
>
> This function is generally useful for file-systems that use the pagecache.
> I simply chose to highlight the most obvious user that benefits from it (and
> so that the function is introduced with a user).
>
> I haven't identified any other specific users of vmap_file() myself. I know
> Matthew has some other ideas for it; I've cc-ed him so he can chime in.
Not much to add but just to confirm - yep, this seems like it might be
useful as a part of the solution to the page cache perf issue[1] with
ASI that I spoke about (briefly and chaotically) at the end of the
LSF/MM/BPF session[0] on ASI this year.
[0] https://lwn.net/Articles/1016013/
[1] https://lore.kernel.org/linux-mm/20250129144320.2675822-1-jackmanb@google.com/
But, for the moment this is all still pretty vague stuff, not at all
clear yet that this idea makes total sense. Hopefully I'll be able to
follow up in a few weeks after I've made some time to stare at/prototype
things.
next prev parent reply other threads:[~2025-04-14 17:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 0:18 [PATCH 0/2] vmalloc: Introduce vmap_file() Vishal Moola (Oracle)
2025-01-31 0:18 ` [PATCH 1/2] mm/vmalloc: " Vishal Moola (Oracle)
2025-01-31 7:09 ` Christoph Hellwig
2025-02-03 19:23 ` Vishal Moola
2025-01-31 0:18 ` [PATCH 2/2] drm: Use vmap_file() in shmem_pin_map() Vishal Moola (Oracle)
2025-01-31 0:48 ` [PATCH 0/2] vmalloc: Introduce vmap_file() Andrew Morton
2025-02-03 18:53 ` Vishal Moola
2025-04-08 14:04 ` Brendan Jackman [this message]
2025-01-31 7:10 ` Christoph Hellwig
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=D91BB945EKGW.UZSCJRUM034H@google.com \
--to=jackmanb@google.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=urezki@gmail.com \
--cc=vishal.moola@gmail.com \
--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.