linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jue Wang <juew@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>,
	almasrymina@google.com,  dave.hansen@linux.intel.com,
	gthelen@google.com, jiaqiyan@google.com,  linux-mm@kvack.org,
	naoya.horiguchi@nec.com, seanjc@google.com,  tony.luck@intel.com
Subject: Re: [RFC] Expose a memory poison detector ioctl to user space.
Date: Fri, 29 Apr 2022 15:53:14 -0700	[thread overview]
Message-ID: <CAPcxDJ4O1kDn9riRNbNBUYi749+ZdwFKY3-BOv9gwRVOToqxpQ@mail.gmail.com> (raw)
In-Reply-To: <d5bc6358-6d9b-f2e8-c4d0-541b87de8252@intel.com>

On Fri, Apr 29, 2022 at 3:29 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 4/29/22 14:32, Jue Wang wrote:
> > On Fri, Apr 29, 2022 at 2:10 PM Dave Hansen <dave.hansen@intel.com> wrote:
> >> I wouldn't go that far.  The unaccepted TDX guest memory thing is just
> >> the obvious one at the moment.  There are a whole ton of other guest
> >> ballooning mechanisms out there and I'm not sure that all of them are
> >> happy to let you touch ballooned-away memory.
> >
> > This type of scanning is intended to be run on the host side. That
> > should avoid concerns around the guest ballooning or any effects to
> > the host side reclaim that's based on the guest's working set.
>
> Hint: Talk is cheap.  Just saying how it is intended doesn't avoid
> concerns.
>
> Saying how it is intended, then backing up that intent with code and
> deliberate design that matches that intent would be nice.
>
> > I don't know why a guest wants to spend its CPU cycles and pollute its
> > caches etc to run this scanner, anyway. This should be a benefit
> > provide by the cloud platform transparently to the guest.
>
> "This should only be used by and made available by cloud providers!" ...
> says the cloud provider. ;)

This is a much better way to put it.

How to express in design that some kernel component that is "best to
be used by and made available by cloud providers" is what I like to
get some feedback on. :-)

>
> Also, who said anything about polluting the caches?  Aren't there lots
> of reasons for a memory poison detector to intentionally not use the
> caches?  First, you really *do* always want to go to memory.  That's
> kinda the point.  If this code hits the caches, it's kinda pointless.
>
> Second, you want this code to have a low profile.  Not polluting the
> caches seems like a good way to have a low profile.
>

We were experimenting with some non-temporal prefetch hint
(prefetchnta) that worked as intended based on perf measurement. The
pollution to LLC is minimal but non-zero.

This is definitely an area we want to keep iterating on, love to hear feedback.

Thanks,
-Jue


  reply	other threads:[~2022-04-29 22:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25 16:34 Jue Wang
2022-04-26 15:40 ` Dave Hansen
2022-04-26 17:57   ` Jue Wang
2022-04-26 18:02     ` Jue Wang
2022-04-26 18:21       ` Dave Hansen
2022-04-26 19:25         ` Jue Wang
2022-04-26 19:52           ` Luck, Tony
2022-04-26 20:06             ` Jue Wang
2022-04-26 18:20     ` Dave Hansen
2022-04-26 19:23       ` Jue Wang
2022-04-26 19:39         ` Dave Hansen
2022-04-26 19:50           ` Jue Wang
2022-04-28 16:15           ` Erdem Aktas
2022-04-28 16:34             ` Dave Hansen
2022-04-29 19:46               ` Jue Wang
2022-04-29 21:10                 ` Dave Hansen
2022-04-29 21:32                   ` Jue Wang
2022-04-29 21:44                     ` Jue Wang
2022-04-29 22:29                     ` Dave Hansen
2022-04-29 22:53                       ` Jue Wang [this message]
2022-05-02 15:30                 ` Dave Hansen
2022-05-02 17:19           ` David Hildenbrand
2022-05-02 17:30             ` Jue Wang
2022-05-02 17:33               ` David Hildenbrand
2022-05-02 17:36                 ` Jue Wang
2022-05-02 17:38                   ` David Hildenbrand

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=CAPcxDJ4O1kDn9riRNbNBUYi749+ZdwFKY3-BOv9gwRVOToqxpQ@mail.gmail.com \
    --to=juew@google.com \
    --cc=almasrymina@google.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=erdemaktas@google.com \
    --cc=gthelen@google.com \
    --cc=jiaqiyan@google.com \
    --cc=linux-mm@kvack.org \
    --cc=naoya.horiguchi@nec.com \
    --cc=seanjc@google.com \
    --cc=tony.luck@intel.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