From: Alex Thorlton <athorlton@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: Alex Thorlton <athorlton@sgi.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
kirill.shutemov@linux.intel.com, Ingo Molnar <mingo@kernel.org>,
Hugh Dickins <hughd@google.com>,
lliubbo@gmail.com, Johannes Weiner <hannes@cmpxchg.org>,
srivatsa.bhat@linux.vnet.ibm.com,
Dave Hansen <dave.hansen@linux.intel.com>,
dfults@sgi.com, hedi@sgi.com
Subject: Re: [patch] mm, thp: do not allow thp faults to avoid cpuset restrictions
Date: Wed, 23 Jul 2014 18:20:38 -0500 [thread overview]
Message-ID: <20140723232038.GV8578@sgi.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407231545520.1389@chino.kir.corp.google.com>
On Wed, Jul 23, 2014 at 03:50:09PM -0700, David Rientjes wrote:
> The page allocator relies on __GFP_WAIT to determine if ALLOC_CPUSET
> should be set in allocflags. ALLOC_CPUSET controls if a page allocation
> should be restricted only to the set of allowed cpuset mems.
>
> Transparent hugepages clears __GFP_WAIT when defrag is disabled to prevent
> the fault path from using memory compaction or direct reclaim. Thus, it
> is unfairly able to allocate outside of its cpuset mems restriction as a
> side-effect.
>
> This patch ensures that ALLOC_CPUSET is only cleared when the gfp mask is
> truly GFP_ATOMIC by verifying it is also not a thp allocation.
Tested. Works as expected.
Tested-by: Alex Thorlton <athorlton@sgi.com>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Alex Thorlton <athorlton@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: Alex Thorlton <athorlton@sgi.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
kirill.shutemov@linux.intel.com, Ingo Molnar <mingo@kernel.org>,
Hugh Dickins <hughd@google.com>,
lliubbo@gmail.com, Johannes Weiner <hannes@cmpxchg.org>,
srivatsa.bhat@linux.vnet.ibm.com,
Dave Hansen <dave.hansen@linux.intel.com>,
dfults@sgi.com, hedi@sgi.com
Subject: Re: [patch] mm, thp: do not allow thp faults to avoid cpuset restrictions
Date: Wed, 23 Jul 2014 18:20:38 -0500 [thread overview]
Message-ID: <20140723232038.GV8578@sgi.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407231545520.1389@chino.kir.corp.google.com>
On Wed, Jul 23, 2014 at 03:50:09PM -0700, David Rientjes wrote:
> The page allocator relies on __GFP_WAIT to determine if ALLOC_CPUSET
> should be set in allocflags. ALLOC_CPUSET controls if a page allocation
> should be restricted only to the set of allowed cpuset mems.
>
> Transparent hugepages clears __GFP_WAIT when defrag is disabled to prevent
> the fault path from using memory compaction or direct reclaim. Thus, it
> is unfairly able to allocate outside of its cpuset mems restriction as a
> side-effect.
>
> This patch ensures that ALLOC_CPUSET is only cleared when the gfp mask is
> truly GFP_ATOMIC by verifying it is also not a thp allocation.
Tested. Works as expected.
Tested-by: Alex Thorlton <athorlton@sgi.com>
next prev parent reply other threads:[~2014-07-23 23:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 22:05 [BUG] THP allocations escape cpuset when defrag is off Alex Thorlton
2014-07-23 22:05 ` Alex Thorlton
2014-07-23 22:28 ` David Rientjes
2014-07-23 22:28 ` David Rientjes
2014-07-23 22:50 ` [patch] mm, thp: do not allow thp faults to avoid cpuset restrictions David Rientjes
2014-07-23 22:50 ` David Rientjes
2014-07-23 23:20 ` Alex Thorlton [this message]
2014-07-23 23:20 ` Alex Thorlton
2014-07-25 9:14 ` Michal Hocko
2014-07-25 9:14 ` Michal Hocko
2014-07-23 22:57 ` [BUG] THP allocations escape cpuset when defrag is off Alex Thorlton
2014-07-23 22:57 ` Alex Thorlton
2014-07-23 23:05 ` David Rientjes
2014-07-23 23:05 ` 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=20140723232038.GV8578@sgi.com \
--to=athorlton@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dfults@sgi.com \
--cc=hannes@cmpxchg.org \
--cc=hedi@sgi.com \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lliubbo@gmail.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.