linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: "Gupta, Pankaj" <pankaj.gupta@amd.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [LSF/MM/BPF TOPIC] Virtual Machine Memory Passthrough
Date: Wed, 22 Feb 2023 13:18:50 -0500	[thread overview]
Message-ID: <CA+CK2bACxoi0DsV=eJ_5t4PFbbHjDvHz1kBC9-tL0zsTP062Gg@mail.gmail.com> (raw)
In-Reply-To: <b079ff5c-0ded-1ed6-15ed-603972ac23b4@amd.com>

> Coming from the virtio-pmem and some free page hinting background, I am
> interested in this discussion. I saw your proposal about single owner
> memory driver in other thread and could not entirely link the dots about
> applicability of the idea with "reducing the memory footprint overhead
> for virtual machines". Do we plan to co-ordinate guest memory state with
> corresponding host state for efficient memory reclaim decisions?
> Or something entirely different we are targeting here?

Hi Pankaj,

The plan is to have a driver /dev/memctl and corresponding VMM agent
that synchronously passes information about how guest would like its
memory to be backed on the host.

For example the following information can come from guest for a range
of physical addresses:
MADV_NOHUGEPAGE
MADV_HUGEPAGE
MADV_DONTNEED
PR_SET_VMA_ANON_NAME
etc.

All together this should help by doing memory management operations
only on the host side, and reduce the number of operations that are
performed on the guest.

The /dev/som can help with allowing support for anonymous memory in
the guest with 1G pages that are only partially backed on the host
side, thus yielding to faster guestVA hostPA translations.

Pasha


  reply	other threads:[~2023-02-22 18:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-20 16:31 Pasha Tatashin
2023-02-20 23:51 ` Gavin Shan
2023-02-22 13:43   ` Pasha Tatashin
2023-02-22 15:31     ` Zi Yan
2023-02-22 15:43       ` Pasha Tatashin
2023-02-21  4:38 ` Zhu Yanjun
2023-02-22 13:44   ` Pasha Tatashin
2023-02-22 17:08 ` Gupta, Pankaj
2023-02-22 18:18   ` Pasha Tatashin [this message]
2023-02-22 20:27     ` Gupta, Pankaj
2023-02-22 20:56       ` Pasha Tatashin
2023-02-23  9:11         ` Gupta, Pankaj

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='CA+CK2bACxoi0DsV=eJ_5t4PFbbHjDvHz1kBC9-tL0zsTP062Gg@mail.gmail.com' \
    --to=pasha.tatashin@soleen.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=pankaj.gupta@amd.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