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

[Alexander Duyck <alexander.h.duyck@linux.intel.com>]

On Fri, 2019-11-08 at 10:57 +0100, Michal Hocko wrote:
> On Thu 07-11-19 10:12:21, Alexander Duyck wrote:
> > On Thu, 2019-11-07 at 18:46 +0100, Michal Hocko wrote:
> [...]
> > > 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 fully understand this! And I also feel the frustration. Been through
> that several times.
> 
> > 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.
> 
> Sure, keeping the code in sync is an additional burden. Having the code
> in just pushes the burden to everybody touching that subsystem in the
> future though. This is the maintenance cost we have to consider. Your
> approach of integrating a very narrow feature into the core allocator
> will require considering that usecase for future changes in the
> allocator. Maintaining metadata elsewhere doesn't impose that
> maintenance cost.
> 
> Can we agree on this at least? Because feel we are circling around in
> this and previous discussions.

Not really. The problem as I see it with external metadata is that it
creates the opportunity for issues like what I ran into with compaction.
It isn't necessarily maintaining any metadata in the page but instead is
has a massive effect on things since it is essentially churning the free
lists. In my mind the main difference is just how visible the
intrusiveness is, not necessarily if it is intrusive or not. The end
result is things are becoming more ossified either way.

> > Then other changes can
> > be rebased on it instead of having to rebase it around other changes that
> > are going on.
> 
> Well, that is not a real argument because alternatives are not an
> incremental change from the allocator POV. It is a different approach of
> maintaining metadata. Sure a different approach could replace your
> implementation (if it was merged) but what is the point of merging an
> approach that would be replaced? Just because you do not want to
> maintain your implmentation off tree? That is a poor argument to me.

It is more than the maintenance cost though. So one thing having the code
in the mm tree and linux-next gets me is more visibility and more review.
At this point the code just rots if I am sitting on it waiting for a
better alternative. What is the point in writing it if I am just sitting
on it? I am writing it with the goal of getting it upstream. I need to see
that there is a path for the patch set that ends in that direction or I am
just wasting time.

> I completely agree with Mel. Let's start with a simple solution first
> (using existing page isolation interfaces sound like a good start to
> interact with the page allocator), establish a decent API for virtio
> and start optimizing from there.

This has been brought up a few times but I don't recall seeing it
discussed anywhere. How do you see the page isolation interfaces being
used to handle the free page reporting case?

> Last but not least, I would also recommend to be more explicit about
> workloads which are going to benefit from those performance optimizations.
> So far I have only seen some micro benchmarks results. Do we have any
> real workloads and see how your approach behaves so that we can compare
> that to the other approach?

I think with some of my early versions I had a fairly simple test that
demonstrated the advantage of the approach by basically just starting up
enough VMs to create an overcommit situation and then running memhog on
each one in series, and then timing the second pass though them. If I
recall it was a matter of something like 6 to 7 seconds versus 45 seconds
per VM tested. Would something like that work or do you have another
suggestion?

I'm still somewhat new to doing development in the mm area, so of my tests
have consisted of variants of things from will-it-scale and the like. I'm
just wondering if there is anything you would recommend?