From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
Nitesh Narayan Lal <nitesh@redhat.com>,
kvm list <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Paolo Bonzini <pbonzini@redhat.com>,
lcapitulino@redhat.com, pagupta@redhat.com, wei.w.wang@intel.com,
Yang Zhang <yang.zhang.wz@gmail.com>,
Rik van Riel <riel@surriel.com>,
dodgen@google.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
dhildenb@redhat.com, Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting
Date: Thu, 7 Mar 2019 21:24:02 -0500 [thread overview]
Message-ID: <20190307212253-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ebca2674-ac15-f1a9-87a4-2ee17a257e4c@redhat.com>
On Thu, Mar 07, 2019 at 08:27:32PM +0100, David Hildenbrand wrote:
> On 07.03.19 19:53, Michael S. Tsirkin wrote:
> > On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> >> To that end what I think w may want to do is instead just walk the LRU
> >> list for a given zone/order in reverse order so that we can try to
> >> identify the pages that are most likely to be cold and unused and
> >> those are the first ones we want to be hinting on rather than the ones
> >> that were just freed. If we can look at doing something like adding a
> >> jiffies value to the page indicating when it was last freed we could
> >> even have a good point for determining when we should stop processing
> >> pages in a given zone/order list.
> >>
> >> In reality the approach wouldn't be too different from what you are
> >> doing now, the only real difference would be that we would just want
> >> to walk the LRU list for the given zone/order rather then pulling
> >> hints on what to free from the calls to free_one_page. In addition we
> >> would need to add a couple bits to indicate if the page has been
> >> hinted on, is in the middle of getting hinted on, and something such
> >> as the jiffies value I mentioned which we could use to determine how
> >> old the page is.
> >
> > Do we really need bits in the page?
> > Would it be bad to just have a separate hint list?
> >
> > If you run out of free memory you can check the hint
> > list, if you find stuff there you can spin
> > or kick the hypervisor to hurry up.
> >
> > Core mm/ changes, so nothing's easy, I know.
>
> We evaluated the idea of busy spinning on some bit/list entry a while
> ago. While it sounds interesting, it is usually not what we want and has
> other negative performance impacts.
>
> Talking about "marking" pages, what we actually would want is to rework
> the buddy to skip over these "marked" pages and only really spin in case
> there are no other pages left. Allocation paths should only ever be
> blocked if OOM, not if just some hinting activity is going on on another
> VCPU.
>
> However as you correctly say: "core mm changes". New page flag?
> Basically impossible.
Well not exactly. page bits are at a premium but only for
*allocated* pages. pages in the buddy are free and there are
some unused bits for these.
> Reuse another one? Can easily get horrbily
> confusing and can easily get rejected upstream. What about the buddy
> wanting to merge pages that are marked (assuming we also want something
> < MAX_ORDER - 1)? This smells like possibly heavy core mm changes.
>
> Lesson learned: Avoid such heavy changes. Especially in the first shot.
>
> The interesting thing about Nitesh's aproach right now is that we can
> easily rework these details later on. The host->guest interface will
> stay the same. Instead of temporarily taking pages out of the buddy, we
> could e.g. mark them and make the buddy or other users skip over them.
>
> --
>
> Thanks,
>
> David / dhildenb
next prev parent reply other threads:[~2019-03-08 2:24 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 15:50 [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting Nitesh Narayan Lal
2019-03-06 15:50 ` [RFC][Patch v9 1/6] KVM: Guest free page hinting support Nitesh Narayan Lal
2019-03-06 23:43 ` Alexander Duyck
2019-03-07 19:32 ` Nitesh Narayan Lal
2019-03-06 15:50 ` [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages Nitesh Narayan Lal
2019-03-07 18:30 ` Alexander Duyck
2019-03-07 19:23 ` Nitesh Narayan Lal
2019-03-07 19:30 ` David Hildenbrand
2019-03-07 21:32 ` Alexander Duyck
2019-03-07 21:40 ` David Hildenbrand
2019-03-07 22:35 ` Alexander Duyck
2019-03-08 2:28 ` Michael S. Tsirkin
2019-03-08 2:32 ` Michael S. Tsirkin
2019-03-08 18:06 ` Alexander Duyck
2019-03-08 18:59 ` Michael S. Tsirkin
2019-03-08 19:10 ` Nitesh Narayan Lal
2019-03-08 19:25 ` Alexander Duyck
2019-03-08 19:38 ` Nitesh Narayan Lal
2019-03-08 21:39 ` Alexander Duyck
2019-03-12 19:46 ` Nitesh Narayan Lal
2019-03-12 21:13 ` Alexander Duyck
2019-03-12 21:53 ` David Hildenbrand
2019-03-12 22:56 ` Alexander Duyck
2019-03-13 11:54 ` Nitesh Narayan Lal
2019-03-13 12:17 ` David Hildenbrand
2019-03-13 13:08 ` Nitesh Narayan Lal
2019-03-13 16:37 ` Alexander Duyck
2019-03-13 16:39 ` David Hildenbrand
2019-03-13 22:54 ` Alexander Duyck
2019-03-13 23:18 ` David Hildenbrand
2019-03-06 15:50 ` [RFC][Patch v9 3/6] KVM: Enables the kernel to report isolated pages Nitesh Narayan Lal
2019-03-06 21:30 ` Alexander Duyck
2019-03-07 13:23 ` Nitesh Narayan Lal
2019-03-06 15:50 ` [RFC][Patch v9 4/6] KVM: Reporting page poisoning value to the host Nitesh Narayan Lal
2019-03-06 15:50 ` [RFC][Patch v9 5/6] KVM: Enabling guest free page hinting via static key Nitesh Narayan Lal
2019-03-06 15:50 ` [RFC][Patch v9 6/6] KVM: Adding tracepoints for guest free page hinting Nitesh Narayan Lal
2019-03-06 15:52 ` [RFC][QEMU Patch] KVM: Enable QEMU to free the pages hinted by the guest Nitesh Narayan Lal
2019-03-06 23:49 ` Alexander Duyck
2019-03-07 0:35 ` Alexander Duyck
2019-03-07 12:23 ` Nitesh Narayan Lal
2019-03-06 16:09 ` [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting Michael S. Tsirkin
2019-03-06 18:07 ` Nitesh Narayan Lal
2019-03-06 18:12 ` Michael S. Tsirkin
2019-03-06 18:30 ` Nitesh Narayan Lal
2019-03-06 18:38 ` Michael S. Tsirkin
2019-03-06 18:40 ` Nitesh Narayan Lal
2019-03-06 18:43 ` Alexander Duyck
2019-03-06 18:43 ` Michael S. Tsirkin
2019-03-06 18:59 ` David Hildenbrand
2019-03-06 19:08 ` Alexander Duyck
2019-03-06 19:18 ` David Hildenbrand
2019-03-06 19:24 ` Alexander Duyck
2019-03-06 20:31 ` Nitesh Narayan Lal
2019-03-06 20:32 ` Michael S. Tsirkin
2019-03-06 21:40 ` David Hildenbrand
2019-03-06 22:18 ` Michael S. Tsirkin
2019-03-06 23:12 ` Alexander Duyck
2019-03-14 16:42 ` Nitesh Narayan Lal
2019-03-14 16:58 ` Alexander Duyck
2019-03-18 15:57 ` Nitesh Narayan Lal
2019-03-19 13:33 ` David Hildenbrand
2019-03-19 16:04 ` Nitesh Narayan Lal
2019-03-19 17:38 ` Alexander Duyck
2019-03-19 17:59 ` Nitesh Narayan Lal
2019-03-20 13:18 ` Nitesh Narayan Lal
2019-03-25 14:27 ` Nitesh Narayan Lal
2019-03-25 15:37 ` Michael S. Tsirkin
2019-03-25 15:42 ` Nitesh Narayan Lal
2019-03-06 18:00 ` Alexander Duyck
2019-03-06 19:07 ` Nitesh Narayan Lal
2019-03-06 22:05 ` Alexander Duyck
2019-03-07 13:09 ` Nitesh Narayan Lal
2019-03-07 18:45 ` Alexander Duyck
2019-03-07 18:53 ` Michael S. Tsirkin
2019-03-07 19:27 ` David Hildenbrand
2019-03-08 2:24 ` Michael S. Tsirkin [this message]
2019-03-08 11:53 ` David Hildenbrand
2019-03-07 21:14 ` Alexander Duyck
2019-03-07 21:28 ` David Hildenbrand
2019-03-07 22:19 ` Alexander Duyck
2019-03-07 19:45 ` Nitesh Narayan Lal
2019-03-07 19:49 ` David Hildenbrand
2019-03-07 18:46 ` Michael S. Tsirkin
2019-03-12 19:58 ` 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=20190307212253-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aarcange@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=david@redhat.com \
--cc=dhildenb@redhat.com \
--cc=dodgen@google.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nitesh@redhat.com \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@surriel.com \
--cc=wei.w.wang@intel.com \
--cc=yang.zhang.wz@gmail.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;
as well as URLs for NNTP newsgroup(s).