On Fri 21-12-18 14:23:13, David Rientjes wrote: > On Fri, 21 Dec 2018, Andrew Morton wrote: > > > > On Fri 21-12-18 11:06:25, Vlastimil Babka wrote: > > > [...] > > > > There's also Michal's series to expand THP eligibility reporting. If it > > > > would be feasible for you to switch to that implementation in your > > > > userspace, and perhaps only locally and temporarily add your patch to > > > > your currently used older kernel versions, then the benefit would be one > > > > less obscure exception in the kernel API. > > > > > > Agreed. With this patch there is no way to check for the actual state of > > > the madvise on the mapping reliably. So the only reason the flag is > > > actually exported. > > > > So where does this leave us? > > > > Before the patch that broke userspace, it had one way to determine if a > vma was eligible for being backed by transparent hugepages: the global thp > setting (not enabled == "never") and smaps. Smaps would expose through > VmFlags whether the vma was eligible based on either MADV_NOHUGEPAGE or > PR_SET_THP_DISABLE. There was no other way. Our usecase measured the > amount of thp eligible memory and compared it with the actual amount of > thp memory, this is used as an indicator of fragmentation issues. This is > used to correlate unexpected performance issues as a result of not being > backed by hugepages with memory fragmentation since we cannot control > everybody using MADV_NOHUGEPAGE or PR_SET_THP_DISABLE. There was simply > no other way of doing that, and it's completely broken by the offending > commit. Please do not break userspace. I didn't and do not plan to break any userspace. You have relied on a (undocumented) side effect of the implementation at the time. Moreover you have relied on something that has been explicitly documented to be unstable. Instead I have provided you with an interface that actually provides a long term maintainable API. This should be somthing you should have done at the time when you needed the functionality. Backporting a proper API to your or whatever older kernel should quite easy and use it in a userspace should be as well. In the presentce of all this. Do we really have to break the API even further? If you absolutely insist then I will not argue further but it strikes me as odd how you keep insisting on bending our APIs, push them to dark corners for very corner case usecases of yours and potentially break other usecases. This is by far not the first example. -- Michal Hocko SUSE Labs
