[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
On Thu, 4 Oct 2018, Michal Hocko wrote:

> > > > > So how about this? (not tested yet but it should be pretty
> > > > > straightforward)
> > > >
> > > > Umm, prctl(PR_GET_THP_DISABLE)?
> > >
> > > /me confused. I thought you want to query for the flag on a
> > > _different_ process.
> >
> > Why would we want to check three locations (system wide setting, prctl
> > setting, madvise setting) to determine if a heap can be backed by thp?
> Because we simply have 3 different ways to control THP? Is this a real
> problem?

And prior to the offending commit, there were three ways to control thp
but two ways to determine if a mapping was eligible for thp based on the
implementation detail of one of those ways. If there are three ways to
control thp, userspace is still in the dark wrt which takes precedence
over the other: we have PR_SET_THP_DISABLE but globally sysfs has it set
to "always", or we have MADV_HUGEPAGE set per smaps but PR_SET_THP_DISABLE
shown in /proc/pid/status, etc.

Which one is the ultimate authority? There's one way to specify it: in a
single per-mapping location that reveals whether that mapping is eligible
for thp or not. So I think it would be a very sane extension so that
smaps reveals if a mapping can be backed by hugepages or not depending on
the helper function thp uses itself to determine if it can fault
hugepages. I don't think we should have three locations to check and then
try to resolve which one takes precedence over the other for each
userspace implementation (and perhaps how the kernel implementation

 \ /
  Last update: 2018-10-04 11:16    [W:1.092 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site