On Thu, 2019-11-07 at 18:46 +0100, Michal Hocko wrote: > On Thu 07-11-19 09:12:01, Dave Hansen wrote: > [...] > > Both approaches seem totally reasonable to me. I don't like Alex's > > pokes into the core of the allocator, but I also don't like Nitesh's > > extra data structures and the (yet unimplemented) code that it will take > > to make them handle all the things they need to like hotplug. > > Well, I would argue that an extra data structure belongs to the user who > is actually using it. Compare that with metadata that is de-facto > maintain athe allocator level which has no real knowledge about the end > user. This is an inherently fragile design as Mel points out in his > earlier email in this thread. I can live with that if that is _really_ > necessary but I would rather not to go that way if there is other way. So to address things I am going to split out the list manipulation into a separate patch as Mel suggested. So in terms of metadata that will leave us with 3 pieces; the PageReported bit, the reported_pages statistics, and the boundary pointers. I will add each one in a separate patch and track the effect of each as I go. > > There's also a common kernel/hypervisor ABI that's *SHARED* between the > > two approaches. That's really the only thing that would marry us to one > > approach versus the other forever. > > > > Am I missing something? What's the harm in merging the implementation > > that's ready today? If a better one comes along, we'll rip out the ~15 > > lines of code in page_alloc.c and merge the better one. > > 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 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. Then other changes can be rebased on it instead of having to rebase it around other changes that are going on.
