From: David Rientjes <rientjes@google.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>, Pravin Shelar <pshelar@nicira.com>,
Jarno Rajahalme <jrajahalme@nicira.com>,
Greg Thelen <gthelen@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
netdev@vger.kernel.org, dev@openvswitch.org
Subject: Re: [patch 1/2] mm: remove GFP_THISNODE
Date: Wed, 25 Feb 2015 17:04:56 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1502251701340.12985@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1502251855330.14795@gentwo.org>
On Wed, 25 Feb 2015, Christoph Lameter wrote:
> On Wed, 25 Feb 2015, David Rientjes wrote:
>
> > NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
>
> Well but then its not removing it. You are replacing it with an inline
> function.
>
Removing GFP_THISNODE, not __GFP_THISNODE. GFP_THISNODE, as the commit
message says, is a special collection of flags that means "never try
reclaim" and people confuse it for __GFP_THISNODE.
There are legitimate usecases where we want __GFP_THISNODE, in other words
restricting the allocation to only a specific node, and try reclaim but
not warn in failure or retry. The most notable example is in the followup
patch for thp, both for page faults and khugepaged, where we want to
target the local node but silently fallback to small pages instead.
This removes the special "no reclaim" behavior of __GFP_THISNODE |
__GFP_NORETRY | __GFP_NOWARN and relies on clearing __GFP_WAIT instead.
--
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>
next prev parent reply other threads:[~2015-02-26 1:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 0:23 David Rientjes
2015-02-26 0:56 ` Christoph Lameter
2015-02-26 1:04 ` David Rientjes [this message]
2015-02-26 8:30 ` Vlastimil Babka
2015-02-27 3:09 ` David Rientjes
2015-02-27 7:34 ` Vlastimil Babka
2015-02-27 22:03 ` David Rientjes
2015-02-27 22:19 ` Vlastimil Babka
2015-02-27 22:31 ` David Rientjes
2015-02-27 22:52 ` Vlastimil Babka
2015-02-27 22:16 ` [patch v2 1/3] " David Rientjes
2015-02-27 22:17 ` [patch v2 2/3] mm, thp: really limit transparent hugepage allocation to local node David Rientjes
2015-03-02 13:47 ` Vlastimil Babka
2015-02-27 22:17 ` [patch v2 3/3] kernel, cpuset: remove exception for __GFP_THISNODE David Rientjes
2015-03-02 13:47 ` Vlastimil Babka
2015-02-27 22:53 ` [patch v2 1/3] mm: remove GFP_THISNODE Christoph Lameter
2015-02-28 3:21 ` David Rientjes
2015-03-02 13:46 ` Vlastimil Babka
2015-03-02 15:46 ` Christoph Lameter
2015-03-02 16:02 ` Vlastimil Babka
2015-03-02 16:08 ` Christoph Lameter
2015-03-02 16:23 ` Vlastimil Babka
2015-03-02 20:40 ` David Rientjes
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.DEB.2.10.1502251701340.12985@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dev@openvswitch.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jrajahalme@nicira.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=pshelar@nicira.com \
--cc=vbabka@suse.cz \
/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