From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: linux-mm@kvack.org
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
linux-perf-users@vger.kernel.org, peterz@infradead.org,
mingo@redhat.com, acme@kernel.org, urezki@gmail.com,
hch@infradead.org, lstoakes@gmail.com
Subject: [RFC PATCH 0/4] Convert perf ringbuffer to folios
Date: Mon, 21 Aug 2023 21:20:12 +0100 [thread overview]
Message-ID: <20230821202016.2910321-1-willy@infradead.org> (raw)
The motivation here is to remove uses of page->mapping as part of the
quest to shrink struct page. I'm unsure about some of this as the perf
ringbuffers present some new challenges that we haven't faced before.
Perf has three different ways of allocating memory for the ring buffer.
There's an individual pages way, a vmalloc way and a physically contiguous
way (for the aux buffers). The fault handler can map all three.
The fault handler can map the _first_ page read-write, but all subsequent
pages are mapped read-only. That makes calling vm_insert_page() not
feasible; that would allow all pages to be mapped read-write (yes?)
So the fault handler sets vmf->page and returns, in order to let
finish_fault() set it up.
I'm not really sure why page/folio->mapping needs to be set by the
fault handler. What goes wrong if we leave it as NULL? Likewise, do
we really need to set ->index? I've taken that out for now, but maybe
that'll make something fail (perhaps an rmap walk? Do we really need to
do rmap walks on device driver mappings?)
I don't like drivers playing these games with pages/folios. I think we
need better support for these kinds of things. Probably in the form of
helpers, given how unusual some of perf's requirements are.
More broadly, we don't have a detailed plan for how vmalloc memory gets
handled in a memdesc world. For the vast majority of vmalloc allocations,
the pages allocated need no descriptor; they're only accessed through
the virtual address by the CPU. This is a case where we need to mmap
the vmalloc memory. There are also cases where we need to do I/O to
vmalloc memory; we need to understand what fields from struct page are
really needed for each of these two requirements.
Matthew Wilcox (Oracle) (4):
perf: Convert perf_mmap_(alloc,free)_page to folios
mm: Add vmalloc_user_node()
perf: Use vmalloc_to_folio()
perf: Use folios for the aux ringbuffer & pagefault path
include/linux/mm.h | 5 +++
include/linux/vmalloc.h | 17 +++++++-
kernel/events/core.c | 13 ++++--
kernel/events/ring_buffer.c | 83 +++++++++++++++++--------------------
mm/vmalloc.c | 9 ++--
5 files changed, 72 insertions(+), 55 deletions(-)
--
2.40.1
next reply other threads:[~2023-08-21 20:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-21 20:20 Matthew Wilcox (Oracle) [this message]
2023-08-21 20:20 ` [RFC PATCH 1/4] perf: Convert perf_mmap_(alloc,free)_page to folios Matthew Wilcox (Oracle)
2023-08-23 7:28 ` Yin Fengwei
2023-08-27 7:33 ` Lorenzo Stoakes
2023-09-13 13:31 ` Peter Zijlstra
2023-09-22 20:19 ` Lorenzo Stoakes
2023-08-21 20:20 ` [RFC PATCH 2/4] mm: Add vmalloc_user_node() Matthew Wilcox (Oracle)
2023-09-13 13:32 ` Peter Zijlstra
2023-08-21 20:20 ` [RFC PATCH 3/4] perf: Use vmalloc_to_folio() Matthew Wilcox (Oracle)
2023-08-22 7:54 ` Zhu Yanjun
2023-08-23 7:30 ` Yin Fengwei
2023-08-23 12:16 ` Matthew Wilcox
2023-08-27 7:22 ` Lorenzo Stoakes
2023-08-21 20:20 ` [RFC PATCH 4/4] perf: Use folios for the aux ringbuffer & pagefault path Matthew Wilcox (Oracle)
2023-08-23 7:38 ` Yin Fengwei
2023-08-23 12:23 ` Matthew Wilcox
2023-08-23 12:45 ` Yin, Fengwei
2023-08-27 8:01 ` Lorenzo Stoakes
2023-08-27 11:50 ` Matthew Wilcox
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=20230821202016.2910321-1-willy@infradead.org \
--to=willy@infradead.org \
--cc=acme@kernel.org \
--cc=hch@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=lstoakes@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=urezki@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).