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

[Michal Hocko <mhocko@kernel.org>]

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.

> 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.

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.

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?
-- 
Michal Hocko
SUSE Labs