On Tue 02-10-18 13:29:42, David Rientjes wrote:

On Tue, 2 Oct 2018, Michal Hocko wrote:

quoted

On Wed 26-09-18 08:06:24, Michal Hocko wrote:

quoted

On Tue 25-09-18 15:04:06, Andrew Morton wrote:

quoted

On Tue, 25 Sep 2018 14:45:19 -0700 (PDT) David Rientjes [off-list ref] wrote:

quoted

quoted

quoted

It is also used in 
automated testing to ensure that vmas get disabled for thp appropriately 
and we used "nh" since that is how PR_SET_THP_DISABLE previously enforced 
this, and those tests now break.

This sounds like a bit of an abuse to me. It shows how an internal
implementation detail leaks out to the userspace which is something we
should try to avoid.

Well, it's already how this has worked for years before commit 
1860033237d4 broke it.  Changing the implementation in the kernel is fine 
as long as you don't break userspace who relies on what is exported to it 
and is the only way to determine if MADV_NOHUGEPAGE is preventing it from 
being backed by hugepages.

1860033237d4 was over a year ago so perhaps we don't need to be
too worried about restoring the old interface.  In which case
we have an opportunity to make improvements such as that suggested
by Michal?

Yeah, can we add a way to export PR_SET_THP_DISABLE to userspace
somehow? E.g. /proc/<pid>/status. It is a process wide thing so
reporting it per VMA sounds strange at best.

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. 
-- 
Michal Hocko
SUSE Labs