linux-kernel - Re: [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160226204628.GC2854@techsingularity.net>
Date:	Fri, 26 Feb 2016 20:46:28 +0000
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Vlastimil Babka <vbabka@...e.cz>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour
 disable it by default

On Fri, Feb 26, 2016 at 08:50:15PM +0100, Andrea Arcangeli wrote:
> Hello Mel,
> 
> On Fri, Feb 26, 2016 at 11:13:16AM +0000, Mel Gorman wrote:
> > 1. By default, "madvise" and direct reclaim/compaction for applications
> >    that specifically requested that behaviour. This will avoid breaking
> >    MADV_HUGEPAGE which you mentioned in a few places
> 
> Defragging memory synchronously only under madvise is fine with me.
> 

I think this is a sensible default though. As you pointed out, those
applications specifically requested it and a delay *should* be acceptable. If
not, then it's a one-liner to change the behaviour.

> > 2. "never" will never reclaim anything and was the default behaviour of
> >    version 1 but will not be the default in version 2.
> > 3. "defer" will wake kswapd which will reclaim or wake kcompactd
> >    whichever is necessary. This is new but avoids stalls while helping
> >    khugepaged do its work quickly in the near future.
> 
> This is an kABI visible change, but it should be ok. I'm not aware of
> any program that parses that file and could get confused.
> 

Neither am I but it'll be a wait and see approach unfortunately to see do
I get the dreaded "you broke an ABI that applications depend upon" report.

> "defer" sounds an interesting default option if it could be made to
> work better.
> 

I was tempted to set it but given that there was a host of reclaim-related
bugs recently I backed off. For example, the last three releases has a
serious bug whereby NUMA machines swapped heavily and no one reported it
(or I missed it).  There is still one excessive reclaiming bug open that
has a potential patch that hasn't been tested so that's still an issue. I
didn't want to muddy the waters further.

> > 4. "always" will direct reclaim/compact just like todays behaviour
> 
> I suspect there are a number of apps that took advantage of the
> "always" setting without realizing it, but we only could notice the
> ones that don't.

Agreed but in itself, it'll be interesting to see if anyone notices.  With
the new default, applications still get huge pages in a lot of cases. It'll
be interesting to report if someone complains about long-term behaviour where
THP utilisation is lower for periods of time until khugepaged recovers it.

> In any case those apps can start to call
> MADV_HUGEPAGE if they don't already and that will provide a definitive
> fix.

Yes or else they set the tunable to always and carry on.

> With this approach MADV_HUGEPAGE will provide the same
> reliability in allocation as before so there will be no problem then.
> 

Yes.

As I believe your concerns have been addressed, can I get an ack on
this patch?

-- 
Mel Gorman
SUSE Labs