Re: [PATCH 1/1] mm: thp: Redefine default THP defrag behaviour disable it by default
From: Mel Gorman
Date: Fri Feb 26 2016 - 15:46:37 EST
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
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.
As I believe your concerns have been addressed, can I get an ack on