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
next prev parent 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