On Mon, 24 Dec 2018, Michal Hocko wrote: > > I'm not interested in having a 100 email thread about this when a clear > > and simple fix exists that actually doesn't break user code. > > You are breaking everybody who really wants to query MADV_NOHUGEPAGE > status by this flag. Is there anybody doing that? I don't know but > I guess we will find out one day. If the fix was a clear win then I > wouldn't say a word. But you are trading one regression which has a > proper fix proposed by another potential breakage which would be hard to > fix without breaking the former one. So this is a lose-lose situation. > No, smaps can be extended to specify anything else it needs to (exact PR_SET_THP_DISABLE usage vs MADV_NOHUGEPAGE). The VmFlag would specify either prior to your commit. This quite severely broke userspace that would check the amount of anonymous memory backed by hugepages for PR_SET_THP_DISABLE processes. What specified it was ineligible in the past no longer existed. So now we have processes being reported as having 0% of their memory backed by hugepages but the indicator that they explicitly disabled it has vanished. When that data is used to correlate fragmentation issues with performance degradations, it's a clear regression. You are free to introduce anything you choose that will remove the ambiguity between PR_SET_THP_DISABLE and MADV_NOHUGEPAGE. That can be done as a complement to the VmFlags behavior which ensures userspace doesn't break. > But yeah, I am not really interested discussing this any further either. > You are clearly not interested about anything beyond your very specific > usecases. Sad, but nothing really new from you. > I'll very proudly be an advocate for not breaking userspace.
