Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc

From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-api@vger.kernel.org
Subject: Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
Date: Tue, 20 Nov 2018 08:48:00 +0100	[thread overview]
Message-ID: <20181120074759.GB22247@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.21.1811191404030.150313@chino.kir.corp.google.com>

On Mon 19-11-18 14:05:34, David Rientjes wrote:
> On Thu, 15 Nov 2018, Michal Hocko wrote:
> 
> > > The userspace had a single way to determine if thp had been disabled for a 
> > > specific vma and that was broken with your commit.  We have since fixed 
> > > it.  Modifying our software stack to start looking for some field 
> > > somewhere else will not help anybody else that this has affected or will 
> > > affect.  I'm interested in not breaking userspace, not trying a wait and 
> > > see approach to see if anybody else complains once we start looking for 
> > > some other field.  The risk outweighs the reward, it already broke us, and 
> > > I'd prefer not to even open the possibility of breaking anybody else.
> > 
> > I very much agree on "do not break userspace" part but this is kind of
> > gray area. VMA flags are a deep internal implementation detail and
> > nobody should really depend on it for anything important. The original
> > motivation for introducing it was CRIU where it is kind of
> > understandable. I would argue they should find a different way but it is
> > just too late for them.
> > 
> > For this particular case there was no other bug report except for yours
> > and if it is possible to fix it on your end then I would really love to
> > make the a sensible user interface to query the status. If we are going
> > to change the semantic of the exported flag again then we risk yet
> > another breakage.
> > 
> > Therefore I am asking whether changing your particular usecase to a new
> > interface is possible because that would allow to have a longerm
> > sensible user interface rather than another kludge which still doesn't
> > cover all the usecases (e.g. there is no way to reliably query the
> > madvise status after your patch).
> > 
> 
> Providing another interface is great, I have no objection other than 
> emitting another line for every vma on the system for smaps is probably 
> overkill for something as rare as PR_SET_THP_DISABLE.

Let me think about a full patch and see how it looks like.

> 
> That said, I think the current handling of the "nh" flag being emitted in 
> smaps is logical and ensures no further userspace breakage.

I have already expressed a concern that there is no way to query for
MADV_NOHUGEPAGE if we overload the flag. So this is not a riskfree
option.

> If that is to 
> be removed, I consider it an unnecessary risk.  That would raised in code 
> review.

-- 
Michal Hocko
SUSE Labs