linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Alexander Duyck <alexander.duyck@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, rkrcmar@redhat.com, x86@kernel.org,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	pbonzini@redhat.com, tglx@linutronix.de,
	akpm@linux-foundation.org
Subject: Re: [RFC PATCH 3/4] kvm: Add guest side support for free memory hints
Date: Mon, 11 Feb 2019 08:31:34 -0800	[thread overview]
Message-ID: <869a170e9232ffbc8ddbcf3d15535e8c6daedbde.camel@linux.intel.com> (raw)
In-Reply-To: <20190209194437-mutt-send-email-mst@kernel.org>

On Sat, 2019-02-09 at 19:49 -0500, Michael S. Tsirkin wrote:
> On Mon, Feb 04, 2019 at 10:15:52AM -0800, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Add guest support for providing free memory hints to the KVM hypervisor for
> > freed pages huge TLB size or larger. I am restricting the size to
> > huge TLB order and larger because the hypercalls are too expensive to be
> > performing one per 4K page.
> 
> Even 2M pages start to get expensive with a TB guest.

Agreed.

> Really it seems we want a virtio ring so we can pass a batch of these.
> E.g. 256 entries, 2M each - that's more like it.

The only issue I see with doing that is that we then have to defer the
freeing. Doing that is going to introduce issues in the guest as we are
going to have pages going unused for some period of time while we wait
for the hint to complete, and we cannot just pull said pages back. I'm
not really a fan of the asynchronous nature of Nitesh's patches for
this reason.

> > Using the huge TLB order became the obvious
> > choice for the order to use as it allows us to avoid fragmentation of higher
> > order memory on the host.
> > 
> > I have limited the functionality so that it doesn't work when page
> > poisoning is enabled. I did this because a write to the page after doing an
> > MADV_DONTNEED would effectively negate the hint, so it would be wasting
> > cycles to do so.
> 
> Again that's leaking host implementation detail into guest interface.
> 
> We are giving guest page hints to host that makes sense,
> weird interactions with other features due to host
> implementation details should be handled by host.

I don't view this as a host implementation detail, this is guest
feature making use of all pages for debugging. If we are placing poison
values in the page then I wouldn't consider them an unused page, it is
being actively used to store the poison value. If we can achieve this
and free the page back to the host then even better, but until the
features can coexist we should not use the page hinting while page
poisoning is enabled.

This is one of the reasons why I was opposed to just disabling page
poisoning when this feature was enabled in Nitesh's patches. If the
guest has page poisoning enabled it is doing something with the page.
It shouldn't be prevented from doing that because the host wants to
have the option to free the pages.


  reply	other threads:[~2019-02-11 16:31 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 18:15 [RFC PATCH 0/4] kvm: Report unused guest pages to host Alexander Duyck
2019-02-04 18:15 ` [RFC PATCH 1/4] madvise: Expose ability to set dontneed from kernel Alexander Duyck
2019-02-04 18:15 ` [RFC PATCH 2/4] kvm: Add host side support for free memory hints Alexander Duyck
2019-02-10  0:44   ` Michael S. Tsirkin
2019-02-11 17:34     ` Alexander Duyck
2019-02-11 17:36       ` Michael S. Tsirkin
2019-02-11 17:41     ` Dave Hansen
2019-02-11 17:48       ` Michael S. Tsirkin
2019-02-11 18:30         ` Alexander Duyck
2019-02-11 19:24           ` Michael S. Tsirkin
2019-02-04 18:15 ` [RFC PATCH 3/4] kvm: Add guest " Alexander Duyck
2019-02-04 19:44   ` Dave Hansen
2019-02-04 20:42     ` Alexander Duyck
2019-02-04 23:00   ` Nadav Amit
2019-02-04 23:37     ` Alexander Duyck
2019-02-05  0:03       ` Nadav Amit
2019-02-05  0:16         ` Alexander Duyck
2019-02-05  1:46           ` Nadav Amit
2019-02-05 18:09             ` Alexander Duyck
2019-02-07 18:21   ` Luiz Capitulino
2019-02-07 18:44     ` Alexander Duyck
2019-02-07 20:02       ` Luiz Capitulino
2019-02-08 21:05       ` Nitesh Narayan Lal
2019-02-08 21:31         ` Alexander Duyck
2019-02-10  0:49   ` Michael S. Tsirkin
2019-02-11 16:31     ` Alexander Duyck [this message]
2019-02-11 17:36       ` Michael S. Tsirkin
2019-02-11 18:10         ` Alexander Duyck
2019-02-11 19:54           ` Michael S. Tsirkin
2019-02-11 21:00             ` Alexander Duyck
2019-02-11 22:52               ` Michael S. Tsirkin
     [not found]                 ` <94462313ccd927d25675f69de459456cf066c1a2.camel@linux.intel.com>
2019-02-12  0:34                   ` Michael S. Tsirkin
2019-02-11 17:48     ` Dave Hansen
2019-02-11 17:58       ` Michael S. Tsirkin
2019-02-11 18:19         ` Dave Hansen
2019-02-11 19:56           ` Michael S. Tsirkin
2019-02-04 18:15 ` [RFC PATCH 4/4] mm: Add merge page notifier Alexander Duyck
2019-02-04 19:40   ` Dave Hansen
2019-02-04 19:51     ` Alexander Duyck
2019-02-10  0:57   ` Michael S. Tsirkin
2019-02-11 13:30     ` Nitesh Narayan Lal
2019-02-11 14:17       ` Michael S. Tsirkin
2019-02-11 16:24         ` Nitesh Narayan Lal
2019-02-11 17:41           ` Michael S. Tsirkin
2019-02-11 18:09             ` Nitesh Narayan Lal
2019-02-11  6:40   ` Aaron Lu
2019-02-11 15:58     ` Alexander Duyck
2019-02-12  2:09       ` Aaron Lu
2019-02-12 17:20         ` Alexander Duyck
2019-02-04 18:19 ` [RFC PATCH QEMU] i386/kvm: Enable paravirtual unused page hint mechanism Alexander Duyck
2019-02-05 17:25 ` [RFC PATCH 0/4] kvm: Report unused guest pages to host Nitesh Narayan Lal
2019-02-05 18:43   ` Alexander Duyck
2019-02-07 14:48 ` Nitesh Narayan Lal
2019-02-07 16:56   ` Alexander Duyck
2019-02-10  0:51 ` Michael S. Tsirkin

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=869a170e9232ffbc8ddbcf3d15535e8c6daedbde.camel@linux.intel.com \
    --to=alexander.h.duyck@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).