From: David Hildenbrand <david@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: 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 22:28:14 +0100 [thread overview]
Message-ID: <f15ccc0d-7c92-bab5-cc24-f49a4fea576f@redhat.com> (raw)
In-Reply-To: <CAKgT0Ue=Y-6-mzqzZ+tJYvfOd4ZeK59okeZKjfJ7LHwhbdpY_w@mail.gmail.com>
On 07.03.19 22:14, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin <mst@redhat.com> 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?
>
> The issue is lists are expensive to search. If we have a single bit in
> the page we can check it as soon as we have the page.
>
>> 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.
>
> This implies you are keeping a separate list of pages for what has
> been hinted on. If we are pulling pages out of the LRU list for that
> it will require the zone lock to move the pages back and forth and for
> higher core counts that isn't going to scale very well, and if you are
> trying to pull out a page that is currently being hinted on you will
> run into the same issue of having to wait for the hint to be completed
> before proceeding.
>
>> Core mm/ changes, so nothing's easy, I know.
>
> We might be able to reuse some existing page flags. For example, there
> is the PG_young and PG_idle flags that would actually be a pretty good
> fit in terms of what we are looking for in behavior. We could set
> PG_young when the page is initially freed, then clear it when we start
> to perform the hint, and set PG_idle once the hint has been completed.
Just noting that when hinting, we have to set all affected sub-page bits
as far as I see.
>
> The check for if we could use a page would be pretty fast as a result
> as well since if PG_young or PG_idle are set it means the page is free
> to use so the check in arch_alloc_page would be pretty cheap since we
> could probably test for both bits in one read.
>
I still dislike spinning on ordinary allocation paths. If we want to go
that way, core mm has to consider these bits and try other pages first.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-03-07 21:28 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
2019-03-08 11:53 ` David Hildenbrand
2019-03-07 21:14 ` Alexander Duyck
2019-03-07 21:28 ` David Hildenbrand [this message]
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=f15ccc0d-7c92-bab5-cc24-f49a4fea576f@redhat.com \
--to=david@redhat.com \
--cc=aarcange@redhat.com \
--cc=alexander.duyck@gmail.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=mst@redhat.com \
--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).