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. -- Mel Gorman SUSE Labs
