From: David Hildenbrand <david@redhat.com>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Alexander Duyck <alexander.duyck@gmail.com>
Cc: Nitesh Narayan Lal <nitesh@redhat.com>,
kvm list <kvm@vger.kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Dave Hansen <dave.hansen@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Yang Zhang <yang.zhang.wz@gmail.com>,
pagupta@redhat.com, Rik van Riel <riel@surriel.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
lcapitulino@redhat.com, wei.w.wang@intel.com,
Andrea Arcangeli <aarcange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
dan.j.williams@intel.com, Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2 4/5] mm: Introduce Hinted pages
Date: Thu, 25 Jul 2019 20:32:50 +0200 [thread overview]
Message-ID: <c200d5cf-90f7-9dca-5061-b6e0233ca089@redhat.com> (raw)
In-Reply-To: <b3568a5422d0f6b88f7c5cb46577db1a43057c04.camel@linux.intel.com>
On 25.07.19 19:38, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 18:48 +0200, David Hildenbrand wrote:
>> On 25.07.19 17:59, Alexander Duyck wrote:
>>> On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
>>>> On 24.07.19 19:03, Alexander Duyck wrote:
>>>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>
> <snip>
>
>>>> Can't we reuse one of the traditional page flags for that, not used
>>>> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
>>>> are dirty.
>>>
>>> Reusing something like the dirty bit would just be confusing in my
>>> opinion. In addition it looks like Xen has also re-purposed PG_dirty
>>> already for another purpose.
>>
>> You brought up waste page management. A dirty bit for unprocessed pages
>> fits perfectly in this context. Regarding XEN, as long as it's not used
>> along with buddy pages, no issue.
>
> I would rather not have to dirty all pages that aren't hinted. That starts
> to get too invasive. Ideally we only modify pages if we are hinting on
> them. That is why I said I didn't like the use of a dirty bit. What we
> want is more of a "guaranteed clean" bit.
Not sure if that is too invasive, but fair enough.
>
>> FWIW, I don't even thing PG_offline matches to what you are using it
>> here for. The pages are not logically offline. They were simply buddy
>> pages that were hinted. (I'd even prefer a separate page type for that
>> instead - if we cannot simply reuse one of the other flags)
>>
>> "Offline pages" that are not actually offline in the context of the
>> buddy is way more confusing.
>
> Right now offline and hinted are essentially the same thing since the
> effect is identical.
No they are not the same thing. Regarding virtio-balloon: You are free
to reuse any hinted pages immediate. Offline pages (a.k.a. inflated) you
might not generally reuse before deflating.
>
> There may be cases in the future where that is not the case, but with the
> current patch set they both result in the pages being evicted from the
> guest.
>
>>> If anything I could probably look at seeing if the PG_private flags
>>> are available when a page is in the buddy allocator which I suspect
>>> they probably are since the only users I currently see appear to be
>>> SLOB and compound pages. Either that or maybe something like PG_head
>>> might make sense since once we start allocating them we are popping
>>> the head off of the boundary list.
>>
>> Would also be fine with me.
>
> Actually I may have found an even better bit if we are going with the
> "reporting" name. I could probably use "PG_uptodate" since it looks like
> most of its uses are related to filesystems. I will wait till I hear from
> Matthew on what bits would be available for use before I update things.
Also fine with me. In the optimal case we (in my opinion)
a) Don't reuse PG_offline
b) Don't use another page type
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-07-25 18:33 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-24 16:54 [PATCH v2 0/5] mm / virtio: Provide support for page hinting Alexander Duyck
2019-07-24 16:56 ` [PATCH v2 1/5] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
2019-07-24 16:58 ` [PATCH v2 2/5] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
2019-07-24 17:00 ` [PATCH v2 3/5] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
2019-07-24 17:03 ` [PATCH v2 4/5] mm: Introduce Hinted pages Alexander Duyck
2019-07-25 8:53 ` David Hildenbrand
2019-07-25 11:46 ` Nitesh Narayan Lal
2019-07-25 11:54 ` David Hildenbrand
2019-07-25 15:59 ` Alexander Duyck
2019-07-25 16:48 ` David Hildenbrand
2019-07-25 17:38 ` Alexander Duyck
2019-07-25 18:32 ` David Hildenbrand [this message]
2019-07-25 20:37 ` Alexander Duyck
2019-07-25 20:44 ` David Hildenbrand
2019-07-26 12:24 ` Nitesh Narayan Lal
2019-07-26 16:38 ` Alexander Duyck
2019-07-24 17:05 ` [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host Alexander Duyck
2019-07-24 19:02 ` Michael S. Tsirkin
2019-07-24 19:07 ` Nitesh Narayan Lal
2019-07-24 19:26 ` Michael S. Tsirkin
2019-07-24 20:37 ` Alexander Duyck
2019-07-24 20:43 ` Michael S. Tsirkin
2019-07-25 14:44 ` Nitesh Narayan Lal
2019-07-25 14:54 ` Michael S. Tsirkin
2019-07-25 14:56 ` Alexander Duyck
2019-07-25 14:59 ` Michael S. Tsirkin
2019-07-25 17:42 ` Nitesh Narayan Lal
2019-07-25 19:54 ` Alexander Duyck
2019-07-24 17:12 ` [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting" Alexander Duyck
2019-07-24 19:02 ` Michael S. Tsirkin
2019-07-24 20:18 ` Alexander Duyck
2019-07-24 20:29 ` Nitesh Narayan Lal
2019-07-24 20:42 ` Michael S. Tsirkin
2019-07-29 16:58 ` Alexander Duyck
2019-07-29 19:25 ` Michael S. Tsirkin
2019-07-29 20:21 ` Alexander Duyck
2019-07-29 20:49 ` Michael S. Tsirkin
2019-07-29 21:37 ` Alexander Duyck
2019-07-29 22:11 ` Michael S. Tsirkin
2019-07-24 20:46 ` Michael S. Tsirkin
2019-07-24 21:14 ` Alexander Duyck
2019-07-25 11:57 ` Nitesh Narayan Lal
2019-07-25 14:57 ` Alexander Duyck
2019-07-24 21:38 ` Michael S. Tsirkin
2019-07-24 22:03 ` Alexander Duyck
2019-07-24 22:08 ` Michael S. Tsirkin
2019-07-24 22:27 ` Alexander Duyck
2019-07-25 6:07 ` Michael S. Tsirkin
2019-07-25 11:35 ` Nitesh Narayan Lal
2019-07-25 15:05 ` Alexander Duyck
2019-07-25 15:16 ` Michael S. Tsirkin
2019-07-25 16:16 ` Alexander Duyck
2019-07-25 17:19 ` Michael S. Tsirkin
2019-07-25 18:25 ` Nitesh Narayan Lal
2019-07-25 20:00 ` Alexander Duyck
2019-07-25 20:14 ` Nitesh Narayan Lal
2019-07-24 18:40 ` [PATCH v2 0/5] mm / virtio: Provide support for page hinting Nitesh Narayan Lal
2019-07-24 18:41 ` David Hildenbrand
2019-07-24 19:31 ` Michael S. Tsirkin
2019-07-24 19:47 ` David Hildenbrand
2019-07-24 19:54 ` Nitesh Narayan Lal
2019-07-24 21:32 ` Michael S. Tsirkin
2019-07-24 19:24 ` Michael S. Tsirkin
2019-07-24 20:27 ` Alexander Duyck
2019-07-24 20:38 ` Nitesh Narayan Lal
2019-07-24 21:00 ` Alexander Duyck
2019-07-25 12:08 ` Nitesh Narayan Lal
2019-07-24 20:38 ` 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=c200d5cf-90f7-9dca-5061-b6e0233ca089@redhat.com \
--to=david@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.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=willy@infradead.org \
--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