From: Srinivas Aji <srinivas.aji@memverge.com>
To: David Hildenbrand <david@redhat.com>
Cc: Linux MM <linux-mm@kvack.org>,
Dan Williams <dan.j.williams@intel.com>,
Vivek Goyal <vgoyal@redhat.com>,
David Woodhouse <dwmw@amazon.com>,
"Gowans, James" <jgowans@amazon.com>,
Yue Li <yue.li@memverge.com>,
Beau Beauchamp <beau.beauchamp@memverge.com>
Subject: Re: [RFC PATCH 0/4] Allow persistent data on DAX device being used as KMEM
Date: Tue, 9 Aug 2022 02:51:17 +0530 [thread overview]
Message-ID: <YvF+TWbB3BMxwxnK@memverge.com> (raw)
In-Reply-To: <922eda33-be7b-f413-6285-33ed0ea0f09e@redhat.com>
On Fri, Aug 05, 2022 at 02:46:26PM +0200, David Hildenbrand wrote:
> Can you explain how "zero copy snapshots of processes" would work, both
>
> a) From a user space POV
> b) From a kernel-internal POV
>
> Especially, what I get is that you have a filesystem on that memory
> region, and all memory that is not used for filesystem blocks can be
> used as ordinary system RAM (a little like shmem, but restricted to dax
> memory regions?).
>
> But how does this interact with zero-copy snapshots?
>
> I feel like I am missing one piece where we really need system RAM as
> part of the bigger picture. Hopefully it's not some hack that converts
> system RAM to file system blocks :)
My proposal probably falls into this category. The idea is that if we
have the persistent filesystem in the same space as system RAM, we
could make most of the process pages part of a snapshot file by
holding references to the these pages and making the pages
copy-on-write for the process, in about the same way a forked child
would. (I still don't have this piece fully worked out. May be there
are reasons why this won't work or will make something else difficult,
and that is why you are advising against it.)
Regarding the userspace and kernel POV:
The userspace operation would be that the process tries to save or
restore its pages using vmsplice(). In the kernel, this would be
implemented using a filesystem which shares pages with system RAM and
uses a zero-copy COW mechanism for those process pages which can be
shared with the filesystem.
I had earlier been thinking of having a different interface to the
kernel, which creates a file with only those memory pages which can be
saved using COW and also indicates to the caller which pages have
actually been saved. But having a vmsplice implementation which does
COW as far as possible keeps the userspace process indicating the
desired function (saving or restoring memory pages) and the kernel
implementation handling the zero copy as an optimization where
possible.
Thanks,
Srinivas
next prev parent reply other threads:[~2022-08-08 21:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 17:57 Srinivas Aji
2022-08-02 18:02 ` [RFC PATCH 1/4] mm/memory_hotplug: Add MHP_ALLOCATE flag which treats hotplugged memory as allocated Srinivas Aji
2022-08-02 18:03 ` [RFC PATCH 0/4] Allow persistent data on DAX device being used as KMEM David Hildenbrand
2022-08-02 18:53 ` Srinivas Aji
2022-08-02 18:07 ` [RFC PATCH 2/4] device-dax: Add framework for keeping persistent data in DAX KMEM Srinivas Aji
2022-08-02 18:10 ` [RFC PATCH 3/4] device-dax: Add a NONE type for DAX KMEM persistence Srinivas Aji
2022-08-02 18:12 ` [RFC PATCH 4/4] device-dax: Add a block device persistent type, BLK, for DAX KMEM Srinivas Aji
2022-08-03 21:19 ` Fabio M. De Francesco
2022-08-05 12:46 ` [RFC PATCH 0/4] Allow persistent data on DAX device being used as KMEM David Hildenbrand
2022-08-08 21:21 ` Srinivas Aji [this message]
2022-08-08 23:05 ` Dan Williams
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=YvF+TWbB3BMxwxnK@memverge.com \
--to=srinivas.aji@memverge.com \
--cc=beau.beauchamp@memverge.com \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=dwmw@amazon.com \
--cc=jgowans@amazon.com \
--cc=linux-mm@kvack.org \
--cc=vgoyal@redhat.com \
--cc=yue.li@memverge.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