On Thu 07-11-19 10:12:21, Alexander Duyck wrote: > On Thu, 2019-11-07 at 18:46 +0100, Michal Hocko wrote: [...] > > 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 fully understand this! And I also feel the frustration. Been through that several times. > 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. Sure, keeping the code in sync is an additional burden. Having the code in just pushes the burden to everybody touching that subsystem in the future though. This is the maintenance cost we have to consider. Your approach of integrating a very narrow feature into the core allocator will require considering that usecase for future changes in the allocator. Maintaining metadata elsewhere doesn't impose that maintenance cost. Can we agree on this at least? Because feel we are circling around in this and previous discussions. > Then other changes can > be rebased on it instead of having to rebase it around other changes that > are going on. Well, that is not a real argument because alternatives are not an incremental change from the allocator POV. It is a different approach of maintaining metadata. Sure a different approach could replace your implementation (if it was merged) but what is the point of merging an approach that would be replaced? Just because you do not want to maintain your implmentation off tree? That is a poor argument to me. I completely agree with Mel. Let's start with a simple solution first (using existing page isolation interfaces sound like a good start to interact with the page allocator), establish a decent API for virtio and start optimizing from there. Last but not least, I would also recommend to be more explicit about workloads which are going to benefit from those performance optimizations. So far I have only seen some micro benchmarks results. Do we have any real workloads and see how your approach behaves so that we can compare that to the other approach? -- Michal Hocko SUSE Labs
