On 11/7/19 9:46 AM, 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. Yeah, I share some of the fragility concern. But, in the end, I was really happy with the solution when things break. With compaction, for instance, it seems just fine to throw all the state out the window and start over. While it might be fragile, it's also rather tolerant once broken, which is a nice property to pair with fragility. >> 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. I _think_ the ask here is for Alex to try to do this with _some_ data structures outside the core allocator's, not necessarily to take Nitesh's approach and get it fully functional.
