linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org, riel@redhat.com, mgorman@suse.de,
	jstancek@redhat.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [merged] mm-page_alloc-reset-aging-cycle-with-gfp_thisnode-v2.patch removed from -mm tree
Date: Thu, 6 Mar 2014 18:04:04 -0500	[thread overview]
Message-ID: <20140306230404.GY6963@cmpxchg.org> (raw)
In-Reply-To: <20140306135635.6999d703429afb7fd3949304@linux-foundation.org>

On Thu, Mar 06, 2014 at 01:56:35PM -0800, Andrew Morton wrote:
> On Thu, 6 Mar 2014 16:49:27 -0500 Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > On Thu, Mar 06, 2014 at 12:37:57PM -0800, akpm@linux-foundation.org wrote:
> > > Subject: [merged] mm-page_alloc-reset-aging-cycle-with-gfp_thisnode-v2.patch removed from -mm tree
> > > To: hannes@cmpxchg.org,jstancek@redhat.com,mgorman@suse.de,riel@redhat.com,stable@kernel.org,mm-commits@vger.kernel.org
> > > From: akpm@linux-foundation.org
> > > Date: Thu, 06 Mar 2014 12:37:57 -0800
> > > 
> > > 
> > > The patch titled
> > >      Subject: mm: page_alloc: exempt GFP_THISNODE allocations from zone fairness
> > > has been removed from the -mm tree.  Its filename was
> > >      mm-page_alloc-reset-aging-cycle-with-gfp_thisnode-v2.patch
> > > 
> > > This patch was dropped because it was merged into mainline or a subsystem tree
> > 
> > Would it make sense to also merge
> > 
> > mm-fix-gfp_thisnode-callers-and-clarify.patch
> > 
> > at this point?  It's not as critical as the GFP_THISNODE exemption,
> > which is why I didn't tag it for stable, but it's a bugfix as well.
> 
> Changelog fail!
> 
> : GFP_THISNODE is for callers that implement their own clever fallback to
> : remote nodes, and so no direct reclaim is invoked.  There are many current
> : users that only want node exclusiveness but still want reclaim to make the
> : allocation happen.  Convert them over to __GFP_THISNODE and update the
> : documentation to clarify GFP_THISNODE semantics.
> 
> what bug does it fix and what are the user-visible effects??

Ok, maybe this is better?

---

GFP_THISNODE is for callers that implement their own clever fallback
to remote nodes.  It restricts the allocation to the specified node
and does not invoke reclaim, assuming that the caller will take care
of it when the fallback fails, e.g. through a subsequent allocation
request without GFP_THISNODE set.

However, many current GFP_THISNODE users only want the node exclusive
aspect of the flag, without actually implementing their own fallback
or triggering reclaim if necessary.  This results in things like page
migration failing prematurely even when there is easily reclaimable
memory available, unless kswapd happens to be running already or a
concurrent allocation attempt triggers the necessary reclaim.

Convert all callsites that don't implement their own fallback strategy
to __GFP_THISNODE.  This restricts the allocation a single node too,
but at the same time allows the allocator to enter the slowpath, wake
kswapd, and invoke direct reclaim if necessary, to make the allocation
happen when memory is full.

--
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:[~2014-03-06 23:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5318dca5.AwhU/92X21JgbpdE%akpm@linux-foundation.org>
2014-03-06 21:49 ` Johannes Weiner
2014-03-06 21:56   ` Andrew Morton
2014-03-06 23:04     ` Johannes Weiner [this message]
2014-03-06 23:12       ` Andrew Morton

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=20140306230404.GY6963@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=jstancek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=riel@redhat.com \
    --cc=stable@kernel.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