From: David Hildenbrand <david@redhat.com>
To: 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>,
Alexander Duyck <alexander.h.duyck@linux.intel.com>
Subject: Re: [PATCH v2 4/5] mm: Introduce Hinted pages
Date: Thu, 25 Jul 2019 18:48:35 +0200 [thread overview]
Message-ID: <f0ac7747-0e18-5039-d341-5dfda8d5780e@redhat.com> (raw)
In-Reply-To: <CAKgT0Ud-UNk0Mbef92hDLpWb2ppVHsmd24R9gEm2N8dujb4iLw@mail.gmail.com>
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>
>
>>> /*
>>> + * PageHinted() is an alias for Offline, however it is not meant to be an
>>> + * exclusive value. It should be combined with PageBuddy() when seen as it
>>> + * is meant to indicate that the page has been scrubbed while waiting in
>>> + * the buddy system.
>>> + */
>>> +PAGE_TYPE_OPS(Hinted, offline)
>>
>>
>> CCing Matthew
>>
>> I am still not sure if I like the idea of having two page types at a time.
>>
>> 1. Once we run out of page type bits (which can happen easily looking at
>> it getting more and more user - e.g., maybe for vmmap pages soon), we
>> might want to convert again back to a value-based, not bit-based type
>> detection. This will certainly make this switch harder.
>
> Shouldn't we wait to cross that bridge until we get there? It wouldn't
> take much to look at either defining the buddy as 2 types for such a
> case, or if needed we could then look at the option of moving over to
> another bit.
I'd rather clarify this now. I am not yet convinced that having multiple
page types at a is a good idea.
>
>> 2. It will complicate the kexec/kdump handling. I assume it can be fixed
>> some way - e.g., making the elf interface aware of the exact notion of
>> page type bits compared to mapcount values we have right now (e.g.,
>> PAGE_BUDDY_MAPCOUNT_VALUE). Not addressed in this series yet.
>
> It does, but not by much. We were already exposing both the buddy and
> offline values. The cahnge could probably be in the executable that
> are accessing the interface to allow the combination of buddy and
> offline.
We are exposing mapcount values, not bit values. So you would
> That is one of the advantages of using the "offline" value to
> also mean hinted since then "hinted" is just a combination of the two
> known values.
We are exposing mapcount values right now, not individual bits. Either
expose the bits manually (and thereby the whole page type scheme) or a
new mapcount value PAGE_BUDDY_OFFLINE_MAPCOUNT_VALUE.
>
>> 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.
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.
>
> 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.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-07-25 16:48 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 [this message]
2019-07-25 17:38 ` Alexander Duyck
2019-07-25 18:32 ` David Hildenbrand
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=f0ac7747-0e18-5039-d341-5dfda8d5780e@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;
as well as URLs for NNTP newsgroup(s).