From: David Rientjes <rientjes@google.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mel Gorman <mgorman@suse.de>, Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
Miao Xie <miaox@cn.fujitsu.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpuset: mm: Remove memory barrier damage from the page allocator
Date: Fri, 2 Mar 2012 15:47:17 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1203021540040.18377@chino.kir.corp.google.com> (raw)
In-Reply-To: <1330723529.11248.237.camel@twins>
On Fri, 2 Mar 2012, Peter Zijlstra wrote:
> Also, for the write side it doesn't really matter, changing mems_allowed
> should be rare and is an 'expensive' operation anyway.
>
It's very expensive even without memory barriers since the page allocator
wraps itself in {get,put}_mems_allowed() until a page or NULL is returned
and an update to current's set of allowed mems can stall indefinitely
trying to change the nodemask during this time. The thread changing
cpuset.mems is holding cgroup_mutex the entire time which locks out
changes, including adding additional nodes to current's set of allowed
mems. If direct reclaim takes a long time or an oom killed task fails to
exit quickly (or the allocation is __GFP_NOFAIL and we just spin
indefinitely holding get_mems_allowed()), then it's not uncommon to see a
write to cpuset.mems taking minutes while holding the mutex, if it ever
actually returns at all.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-03-02 23:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 11:23 Mel Gorman
2012-03-02 16:19 ` Christoph Lameter
2012-03-02 17:43 ` Mel Gorman
2012-03-02 19:53 ` Christoph Lameter
2012-03-02 21:25 ` Peter Zijlstra
2012-03-02 23:47 ` David Rientjes [this message]
2012-03-05 9:44 ` Mel Gorman
2012-03-06 23:31 ` David Rientjes
2012-03-05 9:35 ` Mel Gorman
2012-03-02 21:21 ` Peter Zijlstra
2012-03-05 20:18 ` Andrew Morton
2012-03-06 2:01 ` [RFC PATCH] checkpatch: Warn on use of yield() Joe Perches
2012-03-06 12:45 ` Peter Zijlstra
2012-03-06 13:14 ` Glauber Costa
2012-03-06 13:25 ` Peter Zijlstra
2012-03-06 13:27 ` Glauber Costa
2012-03-06 17:41 ` Joe Perches
2012-03-06 17:54 ` Peter Zijlstra
2012-03-06 18:00 ` Joe Perches
2012-03-06 18:17 ` Joe Perches
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.00.1203021540040.18377@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=miaox@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox