On Fri 23-11-18 16:07:06, Vlastimil Babka wrote: > On 11/20/18 11:35 AM, Michal Hocko wrote: > > From: Michal Hocko <mhocko@xxxxxxxx> > > > > Userspace falls short when trying to find out whether a specific memory > > range is eligible for THP. There are usecases that would like to know > > that > > http://lkml.kernel.org/r/alpine.DEB.2.21.1809251248450.50347@xxxxxxxxxxxxxxxxxxxxxxxxx > > : This is used to identify heap mappings that should be able to fault thp > > : but do not, and they normally point to a low-on-memory or fragmentation > > : issue. > > > > The only way to deduce this now is to query for hg resp. nh flags and > > confronting the state with the global setting. Except that there is > > also PR_SET_THP_DISABLE that might change the picture. So the final > > logic is not trivial. Moreover the eligibility of the vma depends on > > the type of VMA as well. In the past we have supported only anononymous > > memory VMAs but things have changed and shmem based vmas are supported > > as well these days and the query logic gets even more complicated > > because the eligibility depends on the mount option and another global > > configuration knob. > > > > Simplify the current state and report the THP eligibility in > > /proc/<pid>/smaps for each existing vma. Reuse transparent_hugepage_enabled > > for this purpose. The original implementation of this function assumes > > that the caller knows that the vma itself is supported for THP so make > > the core checks into __transparent_hugepage_enabled and use it for > > existing callers. __show_smap just use the new transparent_hugepage_enabled > > which also checks the vma support status (please note that this one has > > to be out of line due to include dependency issues). > > > > Signed-off-by: Michal Hocko <mhocko@xxxxxxxx> > > Not thrilled by this, Any specific concern? > but kernel is always better suited to report this, > than userspace piecing it together from multiple sources, relying on > possibly outdated knowledge of kernel implementation details... yep. > Acked-by: Vlastimil Babka <vbabka@xxxxxxx> Thanks! > A nitpick: > > > --- > > Documentation/filesystems/proc.txt | 3 +++ > > fs/proc/task_mmu.c | 2 ++ > > include/linux/huge_mm.h | 13 ++++++++++++- > > mm/huge_memory.c | 12 +++++++++++- > > mm/memory.c | 4 ++-- > > 5 files changed, 30 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt > > index b1fda309f067..06562bab509a 100644 > > --- a/Documentation/filesystems/proc.txt > > +++ b/Documentation/filesystems/proc.txt > > @@ -425,6 +425,7 @@ SwapPss: 0 kB > > KernelPageSize: 4 kB > > MMUPageSize: 4 kB > > Locked: 0 kB > > +THPeligible: 0 > > I would use THP_Eligible. There are already fields with underscore in smaps. I do not feel strongly. I will wait for more comments and see whether there is some consensus. -- Michal Hocko SUSE Labs
