On Thu 15-11-18 10:02:42, Michal Hocko wrote: > On Wed 14-11-18 13:41:12, David Rientjes wrote: > > On Wed, 14 Nov 2018, Michal Hocko wrote: > > > > > > > > Do you know of any other userspace except your usecase? Is there > > > > > > anything fundamental that would prevent a proper API adoption for > > > > > > you? > > > > > > > > > > > > > > > > Yes, it would require us to go back in time and build patched > > > > > binaries. > > > > > > > > I read that as there is a fundamental problem to update existing > > > > binaries. If that is the case then there surely is no way around it > > > > and another sad page in the screwed up APIs book we provide. > > > > > > > > But I was under impression that the SW stack which actually does the > > > > monitoring is under your controll. Moreover I was under impression that > > > > you do not use the current vanilla kernel so there is no need for an > > > > immediate change on your end. It is trivial to come up with a backward > > > > compatible way to check for the new flag (if it is not present then > > > > fallback to vma flags). > > > > > > > > The userspace had a single way to determine if thp had been disabled for a > > specific vma and that was broken with your commit. We have since fixed > > it. Modifying our software stack to start looking for some field > > somewhere else will not help anybody else that this has affected or will > > affect. I'm interested in not breaking userspace, not trying a wait and > > see approach to see if anybody else complains once we start looking for > > some other field. The risk outweighs the reward, it already broke us, and > > I'd prefer not to even open the possibility of breaking anybody else. > > I very much agree on "do not break userspace" part but this is kind of > gray area. VMA flags are a deep internal implementation detail and > nobody should really depend on it for anything important. The original > motivation for introducing it was CRIU where it is kind of > understandable. I would argue they should find a different way but it is > just too late for them. > > For this particular case there was no other bug report except for yours > and if it is possible to fix it on your end then I would really love to > make the a sensible user interface to query the status. If we are going > to change the semantic of the exported flag again then we risk yet > another breakage. > > Therefore I am asking whether changing your particular usecase to a new > interface is possible because that would allow to have a longerm > sensible user interface rather than another kludge which still doesn't > cover all the usecases (e.g. there is no way to reliably query the > madvise status after your patch).
Btw. this is essentially the same kind of problem as http://lkml.kernel.org/r/20181002100531.gc4...@quack2.suse.cz where the conclusion was to come up with a saner interface rather than mimic the previous one. -- Michal Hocko SUSE Labs
