Re: + mm-introduce-reported-pages.patch added to -mm tree

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
To: Michal Hocko <mhocko@kernel.org>, Dave Hansen <dave.hansen@intel.com>
Cc: David Hildenbrand <david@redhat.com>,
	akpm@linux-foundation.org,  aarcange@redhat.com,
	dan.j.williams@intel.com, konrad.wilk@oracle.com,
	 lcapitulino@redhat.com, mgorman@techsingularity.net,
	mm-commits@vger.kernel.org,  mst@redhat.com, osalvador@suse.de,
	pagupta@redhat.com, pbonzini@redhat.com,  riel@surriel.com,
	vbabka@suse.cz, wei.w.wang@intel.com, willy@infradead.org,
	 yang.zhang.wz@gmail.com, linux-mm@kvack.org
Subject: Re: + mm-introduce-reported-pages.patch added to -mm tree
Date: Thu, 07 Nov 2019 10:12:21 -0800	[thread overview]
Message-ID: <91ccd1e4a9077e22379edbaac2fd8c16897b1f7a.camel@linux.intel.com> (raw)
In-Reply-To: <20191107174644.GA8314@dhcp22.suse.cz>

On Thu, 2019-11-07 at 18:46 +0100, Michal Hocko wrote:
> On Thu 07-11-19 09:12:01, Dave Hansen wrote:
> [...]
> > Both approaches seem totally reasonable to me.  I don't like Alex's
> > pokes into the core of the allocator, but I also don't like Nitesh's
> > extra data structures and the (yet unimplemented) code that it will take
> > to make them handle all the things they need to like hotplug.
> 
> Well, I would argue that an extra data structure belongs to the user who
> is actually using it. Compare that with metadata that is de-facto
> maintain athe allocator level which has no real knowledge about the end
> user. This is an inherently fragile design as Mel points out in his
> earlier email in this thread. I can live with that if that is _really_
> necessary but I would rather not to go that way if there is other way.

So to address things I am going to split out the list manipulation into a
separate patch as Mel suggested. So in terms of metadata that will leave
us with 3 pieces; the PageReported bit, the reported_pages statistics, and
the boundary pointers. I will add each one in a separate patch and track
the effect of each as I go. 

> > There's also a common kernel/hypervisor ABI that's *SHARED* between the
> > two approaches.  That's really the only thing that would marry us to one
> > approach versus the other forever.
> > 
> > Am I missing something?  What's the harm in merging the implementation
> > that's ready today?  If a better one comes along, we'll rip out the ~15
> > lines of code in page_alloc.c and merge the better one.
> 
> I have asked several times why there is such a push and received no
> answer but "this is taking too long" which I honestly do not care much.
> Especially when other virt people tend to agree that there is no need to
> rush here.

Part of the rush, at least from my perspective, is that I don't have
indefinite time to work on this. I am sure you are aware that maintaining
an external patch set can be a real chore and I would prefer to have it
merged and then maintain it as a part of the tree. Then other changes can
be rebased on it instead of having to rebase it around other changes that
are going on.