linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: James Gowans <jgowans@amazon.com>,
	Dave Hansen <dave.hansen@intel.com>,
	 David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	 Mike Rapoport <mike.rapoport@gmail.com>,
	 Pasha Tatashin <tatashin@google.com>,
	Peter Xu <peterx@redhat.com>,  Alexander Graf <graf@amazon.com>,
	Ashish Kalra <ashish.kalra@amd.com>,
	 Tom Lendacky <thomas.lendacky@amd.com>,
	 David Woodhouse <dwmw@amazon.co.uk>,
	 Anthony Yznaga <anthony.yznaga@oracle.com>,
	 Jason Gunthorpe <jgg@nvidia.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Frank van der Linden <fvdl@google.com>,
	Vipin Sharma <vipinsh@google.com>,
	 David Matlack <dmatlack@google.com>,
	 Steve Rutherford <srutherford@google.com>,
	 Erdem Aktas <erdemaktas@google.com>,
	Alper Gun <alpergun@google.com>,
	 Vishal Annapurve <vannapurve@google.com>,
	 Ackerley Tng <ackerleytng@google.com>,
	Sagi Shahar <sagis@google.com>
Cc: linux-mm@kvack.org, kexec@lists.infradead.org
Subject: Re: Pmemfs/guestmemfs discussion recap and open questions
Date: Fri, 25 Oct 2024 23:07:27 -0700 (PDT)	[thread overview]
Message-ID: <5b6613bc-beef-79e6-62ed-23de4dfafe51@google.com> (raw)
In-Reply-To: <f44f317a-2dcb-cfe2-013c-7508907ce3df@google.com>

On Wed, 16 Oct 2024, David Rientjes wrote:

> ----->o-----
> My takeaway: based on the feedback that was provided in the discussion:
> 
>  - we need an allocator abstraction for persistent memory that can return
>    memory with various characteristics: 1GB or not, kernel direct map or
>    not, HVO or not, etc.
> 
>  - built on top of that, we need the ability to carve out very large
>    ranges of memory (cloud provider use case) with NUMA awareness on the
>    kernel command line
> 

Following up on this, I think this physical memory allocator would also be 
possible to use as a backend for hugetlb.  Hopefully this would be an 
allocator that would be generally useful for multiple purposes, something 
like a mm/phys_alloc.c.

Frank van der Linden may also have thoughts on the above?

>  - we also need the ability to be able to dynamically resize this or
>    provide hints at allocation time that memory must be persisted across
>    kexec to support the non-cloud provider use case
> 
>  - we need a filesystem abstraction that map memory of the type that is
>    requested, including guest_memfd and then deal with all the fun of
>    multitenancy since it would be drawing from a finite per-NUMA node
>    pool of persistent memory
> 
>  - absolutely critical to this discussion is defining what is the core
>    infrastructure that is required for a generally acceptable solution
>    and then what builds off of that to be more special cased (like the
>    cloud provider use case or persistent tmpfs use case)
> 
> We're looking to continue that discussion here and then come together 
> again in a few weeks.
> 

We'll be looking to schedule some more time to talk about this topic in 
the Wednesday, November 13 instance of the Linux MM Alignment Session.

After that, I think it would be quite useful to break out the set of 
people that are interested in persisting guest memory across kexec and KHO 
into a separate series to accelerate discussion and next stpes.  Getting 
the requirements and design locked down are critical, so happy to 
facilitate that to any extent possible and welcome everybody interested in 
discussing it.

James, for the guestmemfs discussions, would this work for you?

Alexander, same question for you regarding the KHO work?

It's a global community, so the timing won't work for eveyrbody.  We'd 
plan on sending out summaries of these discussions, such as in this email, 
to solicit feedback and ideas from everybody.

If you're not on the To: or Cc: list already, please email me separatel if 
you're interested in participating and then we can find a regular time.

This is exciting!


  reply	other threads:[~2024-10-26  6:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17  4:42 David Rientjes
2024-10-26  6:07 ` David Rientjes [this message]
2024-10-29 15:32   ` Vishal Annapurve
2024-10-29 16:35   ` Mike Rapoport
2024-10-30 22:43     ` Frank van der Linden

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=5b6613bc-beef-79e6-62ed-23de4dfafe51@google.com \
    --to=rientjes@google.com \
    --cc=ackerleytng@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=alpergun@google.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=ashish.kalra@amd.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=dmatlack@google.com \
    --cc=dwmw@amazon.co.uk \
    --cc=erdemaktas@google.com \
    --cc=fvdl@google.com \
    --cc=graf@amazon.com \
    --cc=jgg@nvidia.com \
    --cc=jgowans@amazon.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.rapoport@gmail.com \
    --cc=peterx@redhat.com \
    --cc=sagis@google.com \
    --cc=srutherford@google.com \
    --cc=tatashin@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.com \
    --cc=vipinsh@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox