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
