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

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

On Fri, 2019-11-08 at 18:41 +0000, Mel Gorman wrote:
> On Fri, Nov 08, 2019 at 08:17:49AM -0800, Alexander Duyck wrote:
> > > <SNIP>
> > > 
> > > From your perspective, I see it's a bit annoying because in the final
> > > result, the code should be identical. However, it'll be a lot clearer
> > > during review what is required, what level of complexity optimisations
> > > add and the performance of it. The changelog should include what metric
> > > you are using to evaluate the performance, the test case and the delta. It
> > > also will be easier from a debugging perspective as minimally a bisection
> > > could identify if a bug was due to the core mechanism itself or one of
> > > the optimisations.  Finally, it leaves open the possibility that someone
> > > can evaluate a completely different set of optimisations. Whatever the
> > > alternative approaches are, the actual interface to virtio ballon surely
> > > is the same (I don't actually know, I just can't see why the virtio ABI
> > > would be depend on how the pages are isolated, tracked and reported).
> > 
> > The virtio-balloon interface is the same at this point between my solution
> > and Nitesh's. So the only real disagreement in terms of the two solutions
> > is about keeping the bit in the page and the list manipulation versus the
> > external bitmap and the hunt and peck approach.
> > 
> 
> This is good news because it means that when/if Nitesh's approach is ready
> that the optimisations can be reverted and the new approach applied and
> give a like-like comparison if appropriate. The core feature and interface
> to userspace would remain the same and stay available regardless of how
> it's optimised. Maybe it's the weekend talking but I think structuring
> the series like that will allow forward progress to be made.

So quick question.

Any issue with me manipulating the lists like you do with the compaction
code? I ask because most of the overhead I was encountering was likely due
to walking the list so many times. If I do the split/splice style logic
that should reduce the total number of trips through the free lists since
I could push the reported pages to the tail of the list. For now I am
working on that as an alternate patch to the existing reported_boundary
approach just as an experiment.

Thanks.

- Alex