From: Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de>
To: <linux-mm@kvack.org>
Cc: Wolfgang Mauerer <wolfgang.mauerer@oth-regensburg.de>,
Mario Mintel <mario.mintel@st.oth-regensburg.de>
Subject: COW in userspace
Date: Fri, 20 Aug 2021 15:13:11 +0200 [thread overview]
Message-ID: <c3a9dd2c-0ee2-ad15-9ec0-93ae5aa6c9cc@oth-regensburg.de> (raw)
Dear mm folks,
I have an issue, where it would be great to have a COW-backed virtual
memory area within an userspace process. I know there's the possibility
to have a file-backed MAP_SHARED vma, which is later duplicated with
MAP_PRIVATE, but that's not exactly what I'm looking for.
Say I have an anonymous page-aligned VMA a, with MAP_PRIVATE and
PROT_RW. Userspace happily writes to/reads from it. At some point in
time, I want to 'snapshot' that single VMA within the context of the
process and without the need to fork(). Say there's something like
a = mmap(0, len, PROT_RW, MAP_ANON | MAP_POPULATE, -1, 0);
[... fill a ...]
b = mmdup(a, len, PROT_READ);
b shall be the new base pointer of a new VMA that is backed by COW
mechanisms. After mmdup, those regular COW mechanisms do the rest: both
VMAs (a and b) will fault on subsequent writes and duplicate the
previously shared physical mapping, pretty much what cow_fault or
shared_fault does.
Afaict, this, or at least something like this is currently not supported
by the kernel. Is that correct? If so, why? Generally spoken, is it a
bad idea?
I digged a bit into the mm code, and I think all the stuff that would be
required is already there, so I wonder what I'm missing.
This is some related work I found on that topic:
https://sfb876.tu-dortmund.de/PublicPublicationFiles/kotthaus_2016a.pdf
They implement mmapcopy(), which pretty much would fulfill my
requirements. However, I still wonder why the kernel doesn't support
something like that by default, so maybe some mm expert could shed light
on this.
Any suggestions welcome!
Thanks
Ralf
next reply other threads:[~2021-08-20 13:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 13:13 Ralf Ramsauer [this message]
2021-08-20 23:12 ` COW in userspace Jerome Glisse
2021-08-23 8:02 ` David Hildenbrand
2021-08-23 10:16 ` [EXT] " Ralf Ramsauer
2021-08-23 10:33 ` David Hildenbrand
2021-08-23 10:49 ` Ralf Ramsauer
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=c3a9dd2c-0ee2-ad15-9ec0-93ae5aa6c9cc@oth-regensburg.de \
--to=ralf.ramsauer@oth-regensburg.de \
--cc=linux-mm@kvack.org \
--cc=mario.mintel@st.oth-regensburg.de \
--cc=wolfgang.mauerer@oth-regensburg.de \
/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).