From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
To: Michal Hocko <mhocko@kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>
Cc: Yang Zhang <yang.zhang.wz@gmail.com>,
Pankaj Gupta <pagupta@redhat.com>, kvm list <kvm@vger.kernel.org>,
David Hildenbrand <david@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
lcapitulino@redhat.com, linux-mm <linux-mm@kvack.org>,
will@kernel.org, Andrea Arcangeli <aarcange@redhat.com>,
virtio-dev@lists.oasis-open.org,
"Michael S. Tsirkin" <mst@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
"Wang, Wei W" <wei.w.wang@intel.com>,
Mel Gorman <mgorman@suse.de>,
ying.huang@intel.com, Rik van Riel <riel@surriel.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>,
Nitesh Narayan Lal <nitesh@redhat.com>,
Dave Hansen <dave.hansen@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Fengguang Wu <fengguang.wu@intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v9 0/8] stg mail -e --version=v9 \
Date: Thu, 12 Sep 2019 08:42:08 -0700 [thread overview]
Message-ID: <b84a3916202a67bcf36da0b6f0e833eb3408339a.camel@linux.intel.com> (raw)
In-Reply-To: <20190912091925.GM4023@dhcp22.suse.cz>
On Thu, 2019-09-12 at 11:19 +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> >
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
>
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.
>
> > In our case the "Reported" page is likely going to be much more
> > expensive to allocate and use then a standard page because it will be
> > faulted back in. In such a case wouldn't it make sense for us to want
> > to keep the pages that don't require faults ahead of those pages in
> > the free_list so that they are more likely to be allocated?
>
> OK, I was suspecting this would pop out. And this is exactly why I
> didn't like an idea of an external code imposing a non obvious constrains
> to the allocator. You simply cannot count with any ordering with the
> page allocator. We used to distinguish cache hot/cold pages in the past
> and pushed pages to the specific end of the free list but that has been
> removed. There are other potential changes like that possible. Shuffling
> is a good recent example.
>
> Anyway I am not a maintainer of this code. I would really like to hear
> opinions from Mel and Vlastimil here (now CCed - the thread starts
> http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain.
One alternative I could do if we are wanting to make things more obvious
would be to add yet another add_to_free_list_XXX function that would be
used specifically for reported pages. The only real requirement I have is
that we have to insert reported pages such that we generate a continuous
block without interleaving non-reported pages in between. So as long as
reported pages are always inserted at the boundary/iterator when we are
actively reporting on a section then I can guarantee the list won't have
gaps formed.
Also as far as the concerns about this being an external user, one thing I
can do is break up the headers a bit and define an internal header in mm/
that defines all the items used by the page allocator, and another in
include/linux/ that defines what is used by devices when receiving the
notifications. It would then help to reduce the likelihood of an outside
entity messing with the page allocator too much.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-09-12 15:42 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
2019-09-09 8:14 ` David Hildenbrand
2019-09-09 15:11 ` Alexander Duyck
2019-09-10 12:11 ` Michal Hocko
2019-09-10 22:14 ` Alexander Duyck
2019-09-10 22:11 ` Alexander Duyck
2019-09-09 9:07 ` Kirill A. Shutemov
2019-09-09 15:12 ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
2019-09-09 8:19 ` David Hildenbrand
2019-09-09 9:47 ` Kirill A. Shutemov
2019-09-09 15:22 ` Alexander Duyck
2019-09-09 15:35 ` Kirill A. Shutemov
2019-09-09 15:37 ` Alexander Duyck
2019-09-09 16:43 ` Alexander Duyck
2019-09-09 17:00 ` Kirill A. Shutemov
2019-09-10 12:20 ` Michal Hocko
2019-09-10 14:48 ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
2019-09-09 8:22 ` David Hildenbrand
2019-09-09 9:56 ` Kirill A. Shutemov
2019-09-09 18:01 ` Alexander Duyck
2019-09-09 18:12 ` Alexander Duyck
2019-09-10 12:23 ` Michal Hocko
2019-09-10 14:46 ` Alexander Duyck
2019-09-10 17:45 ` Michal Hocko
2019-09-10 20:26 ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
2019-09-10 12:27 ` Michal Hocko
2019-09-07 17:25 ` [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h Alexander Duyck
2019-09-09 8:52 ` David Hildenbrand
2019-09-09 15:27 ` Alexander Duyck
2019-09-17 17:48 ` Will Deacon
2019-09-17 20:07 ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 6/8] mm: Introduce Reported pages Alexander Duyck
2019-09-09 14:42 ` Kirill A. Shutemov
2019-09-09 16:25 ` Alexander Duyck
2019-09-09 16:33 ` Kirill A. Shutemov
2019-09-07 17:26 ` [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting Alexander Duyck
2019-09-09 8:59 ` David Hildenbrand
2019-09-09 15:31 ` Alexander Duyck
2019-09-07 17:26 ` [PATCH v9 8/8] virtio-balloon: Add support for providing unused page reports to host Alexander Duyck
2019-09-07 17:34 ` [PATCH v9 0/8] mm / virtio: Provide support for unused page reporting Alexander Duyck
2019-09-10 12:42 ` [PATCH v9 0/8] stg mail -e --version=v9 \ Michal Hocko
2019-09-10 14:42 ` Alexander Duyck
2019-09-10 14:47 ` Michal Hocko
2019-09-10 16:05 ` Alexander Duyck
2019-09-10 16:18 ` [virtio-dev] " Dr. David Alan Gilbert
2019-09-10 16:22 ` David Hildenbrand
2019-09-11 9:23 ` Michael S. Tsirkin
2019-09-11 9:50 ` David Hildenbrand
2019-09-10 17:52 ` Michal Hocko
2019-09-10 18:00 ` Michal Hocko
2019-09-10 20:37 ` Alexander Duyck
2019-09-10 21:23 ` Alexander Duyck
2019-09-11 11:36 ` Michal Hocko
2019-09-11 11:47 ` David Hildenbrand
2019-09-11 12:08 ` Michael S. Tsirkin
2019-09-11 12:19 ` Michal Hocko
2019-09-11 12:25 ` Michal Hocko
2019-09-11 12:42 ` David Hildenbrand
2019-09-11 12:54 ` Michal Hocko
2019-09-11 13:03 ` David Hildenbrand
2019-09-11 13:20 ` Michal Hocko
2019-09-11 13:51 ` Michal Hocko
2019-09-11 16:09 ` David Hildenbrand
2019-09-12 7:16 ` Michal Hocko
2019-09-12 7:47 ` David Hildenbrand
2019-09-12 9:26 ` Michal Hocko
2019-09-12 12:00 ` Nitesh Narayan Lal
2019-09-11 14:03 ` Nitesh Narayan Lal
2019-09-11 16:02 ` David Hildenbrand
2019-09-11 13:19 ` Nitesh Narayan Lal
2019-09-11 12:55 ` Nitesh Narayan Lal
2019-09-11 15:12 ` Alexander Duyck
2019-09-12 9:19 ` Michal Hocko
2019-09-12 10:24 ` Kirill A. Shutemov
2019-09-12 11:11 ` Michal Hocko
2019-09-12 15:42 ` Alexander Duyck [this message]
2019-09-12 16:35 ` Mel Gorman
2019-09-12 17:48 ` Alexander Duyck
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=b84a3916202a67bcf36da0b6f0e833eb3408339a.camel@linux.intel.com \
--to=alexander.h.duyck@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=fengguang.wu@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mst@redhat.com \
--cc=nitesh@redhat.com \
--cc=osalvador@suse.de \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
--cc=virtio-dev@lists.oasis-open.org \
--cc=wei.w.wang@intel.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yang.zhang.wz@gmail.com \
--cc=ying.huang@intel.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).