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.
