linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>,
	David Rientjes <rientjes@google.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Joonsoo Kim <js1304@gmail.com>,
	Hillf Danton <hillf.zj@alibaba-inc.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@suse.com>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers
Date: Tue, 5 Apr 2016 17:55:39 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LSU.2.11.1604051727150.7348@eggly.anvils> (raw)
In-Reply-To: <20160405165826.012236e79db7f396fda546a8@linux-foundation.org>

On Tue, 5 Apr 2016, Andrew Morton wrote:
> On Tue,  5 Apr 2016 13:25:31 +0200 Michal Hocko <mhocko@kernel.org> wrote:
> > -	if (is_thp_gfp_mask(gfp_mask)) {
> > -		/*
> > -		 * If compaction is deferred for high-order allocations, it is
> > -		 * because sync compaction recently failed. If this is the case
> > -		 * and the caller requested a THP allocation, we do not want
> > -		 * to heavily disrupt the system, so we fail the allocation
> > -		 * instead of entering direct reclaim.
> > -		 */
> > -		if (compact_result == COMPACT_DEFERRED)
> > -			goto nopage;
> > -
> > -		/*
> > -		 * Compaction is contended so rather back off than cause
> > -		 * excessive stalls.
> > -		 */
> > -		if(compact_result == COMPACT_CONTENDED)
> > -			goto nopage;
> > -	}
> > +	/*
> > +	 * Checks for THP-specific high-order allocations and back off
> > +	 * if the the compaction backed off
> > +	 */
> > +	if (is_thp_gfp_mask(gfp_mask) && compaction_withdrawn(compact_result))
> > +		goto nopage;
> 
> This change smashed into Hugh's "huge tmpfs: shmem_huge_gfpmask and
> shmem_recovery_gfpmask".
> 
> I ended up doing this:
> 
> 	/* Checks for THP-specific high-order allocations */
> 	if (!is_thp_allocation(gfp_mask, order))
> 		migration_mode = MIGRATE_SYNC_LIGHT;
> 
> 	/*
> 	 * Checks for THP-specific high-order allocations and back off
> 	 * if the the compaction backed off
> 	 */
> 	if (is_thp_allocation(gfp_mask) && compaction_withdrawn(compact_result))
> 		goto nopage;

You'll already have found that is_thp_allocation() needs the order too.
But then you had to drop a hunk out of his 10/11 also to fit with mine.

What you've done may be just right, but I haven't had time to digest
Michal's changes yet (and not yet seen what happens to the PF_KTHREAD
distinction), so I think it will probably end up better if you take
his exactly as he tested and posted them, and drop my 30/31 and 31/31
for now - I can resubmit them (or maybe drop 30 altogether) after I've
pondered and tested a little on top of Michal's.

Huge tmpfs got along fine for many months without 30/31 and 31/31: 30
is just for experimentation, and 31 to reduce the compaction stalls we
saw under some loads.  Maybe I'll find that Michal's rework has changed
the balance there anyway, and something else or nothing at all needed.

(The gfp_mask stuff was very confusing, and it's painful for me, how
~__GFP_KSWAPD_RECLAIM gets used as a secret password to say "THP" and
how to angle compaction - or maybe it's all more straightforward now.)

Many thanks for giving us both this quick exposure!

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-04-06  0:55 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 11:25 [PATCH 00/11] oom detection rework v5 Michal Hocko
2016-04-05 11:25 ` [PATCH 01/11] mm, oom: rework oom detection Michal Hocko
2016-04-05 11:25 ` [PATCH 02/11] mm: throttle on IO only when there are too many dirty and writeback pages Michal Hocko
2016-04-05 11:25 ` [PATCH 03/11] mm, compaction: change COMPACT_ constants into enum Michal Hocko
2016-04-05 11:25 ` [PATCH 04/11] mm, compaction: cover all compaction mode in compact_zone Michal Hocko
2016-04-05 11:25 ` [PATCH 05/11] mm, compaction: distinguish COMPACT_DEFERRED from COMPACT_SKIPPED Michal Hocko
2016-04-11 11:02   ` Vlastimil Babka
2016-04-11 11:24     ` Michal Hocko
2016-04-05 11:25 ` [PATCH 06/11] mm, compaction: distinguish between full and partial COMPACT_COMPLETE Michal Hocko
2016-04-11 12:10   ` Vlastimil Babka
2016-04-11 12:46     ` Michal Hocko
2016-04-11 12:53       ` Vlastimil Babka
2016-04-11 13:27         ` Michal Hocko
2016-04-11 13:42           ` Vlastimil Babka
2016-04-11 13:46             ` Michal Hocko
2016-04-05 11:25 ` [PATCH 07/11] mm, compaction: Update compaction_result ordering Michal Hocko
2016-04-11 12:16   ` Vlastimil Babka
2016-04-05 11:25 ` [PATCH 08/11] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface Michal Hocko
2016-04-11 13:48   ` Vlastimil Babka
2016-04-05 11:25 ` [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers Michal Hocko
2016-04-05 23:58   ` Andrew Morton
2016-04-06  0:55     ` Hugh Dickins [this message]
2016-04-06  9:26       ` Michal Hocko
2016-04-06 17:46       ` Andrew Morton
2016-04-11 14:39   ` Vlastimil Babka
2016-04-11 15:14     ` Michal Hocko
2016-04-11 15:33       ` Michal Hocko
2016-04-12 11:53       ` Vlastimil Babka
2016-04-12 12:23         ` Michal Hocko
2016-04-11 15:40   ` Michal Hocko
2016-04-11 16:07     ` [RFC PATCH] mm: use compaction feedback for thp backoff conditions Michal Hocko
2016-04-12 11:54     ` [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers Vlastimil Babka
2016-04-05 11:25 ` [PATCH 10/11] mm, oom: protect !costly allocations some more Michal Hocko
2016-04-06  0:06   ` Andrew Morton
2016-04-06  9:28     ` Michal Hocko
2016-04-11 14:48   ` Vlastimil Babka
2016-04-05 11:25 ` [PATCH 11/11] mm: consider compaction feedback also for costly allocation Michal Hocko
2016-04-05 12:46   ` Michal Hocko
2016-04-11 15:07   ` Vlastimil Babka
2016-04-05 12:47 ` [PATCH 00/11] oom detection rework v5 Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.11.1604051727150.7348@eggly.anvils \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox