From: Mel Gorman <mgorman@suse.de>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Gilad Ben-Yossef <gilad@benyossef.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Miklos Szeredi <mszeredi@novell.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Greg KH <gregkh@suse.de>, Gong Chen <gong.chen@intel.com>
Subject: Re: [PATCH 2/2] mm: page allocator: Do not drain per-cpu lists via IPI from page allocator context
Date: Thu, 12 Jan 2012 15:37:12 +0000 [thread overview]
Message-ID: <20120112153712.GL4118@suse.de> (raw)
In-Reply-To: <1326381492.2442.188.camel@twins>
On Thu, Jan 12, 2012 at 04:18:12PM +0100, Peter Zijlstra wrote:
> On Wed, 2012-01-11 at 10:11 +0000, Mel Gorman wrote:
> > At least one bug report has
> > been seen on ppc64 against a 3.0 era kernel that looked like a bug
> > receiving interrupts on a CPU being offlined.
>
> Got details on that Mel? The preempt_disable() in on_each_cpu() should
> serialize against the stop_machine() crap in unplug.
I might have added 2 and 2 together and got 5.
The stack trace clearly was while sending IPIs in on_each_cpu() and
always when under memory pressure and stuck in direct reclaim. This was
on !PREEMPT kernels where preempt_disable() is a no-op. That is why I
thought get_online_cpu() would be necessary.
--
Mel Gorman
SUSE Labs
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Gilad Ben-Yossef <gilad@benyossef.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Miklos Szeredi <mszeredi@novell.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Greg KH <gregkh@suse.de>, Gong Chen <gong.chen@intel.com>
Subject: Re: [PATCH 2/2] mm: page allocator: Do not drain per-cpu lists via IPI from page allocator context
Date: Thu, 12 Jan 2012 15:37:12 +0000 [thread overview]
Message-ID: <20120112153712.GL4118@suse.de> (raw)
In-Reply-To: <1326381492.2442.188.camel@twins>
On Thu, Jan 12, 2012 at 04:18:12PM +0100, Peter Zijlstra wrote:
> On Wed, 2012-01-11 at 10:11 +0000, Mel Gorman wrote:
> > At least one bug report has
> > been seen on ppc64 against a 3.0 era kernel that looked like a bug
> > receiving interrupts on a CPU being offlined.
>
> Got details on that Mel? The preempt_disable() in on_each_cpu() should
> serialize against the stop_machine() crap in unplug.
I might have added 2 and 2 together and got 5.
The stack trace clearly was while sending IPIs in on_each_cpu() and
always when under memory pressure and stuck in direct reclaim. This was
on !PREEMPT kernels where preempt_disable() is a no-op. That is why I
thought get_online_cpu() would be necessary.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2012-01-12 15:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 10:11 [RFC PATCH 0/2] Improve reliability of CPU hotplug Mel Gorman
2012-01-11 10:11 ` Mel Gorman
2012-01-11 10:11 ` [PATCH 1/2] fs: sysfs: Do dcache-related updates to sysfs dentries under sysfs_mutex Mel Gorman
2012-01-11 10:11 ` Mel Gorman
2012-01-11 17:11 ` Eric W. Biederman
2012-01-11 17:11 ` Eric W. Biederman
2012-01-11 18:07 ` Mel Gorman
2012-01-11 18:07 ` Mel Gorman
2012-01-11 19:02 ` Eric W. Biederman
2012-01-11 19:02 ` Eric W. Biederman
2012-01-11 10:11 ` [PATCH 2/2] mm: page allocator: Do not drain per-cpu lists via IPI from page allocator context Mel Gorman
2012-01-11 10:11 ` Mel Gorman
2012-01-12 14:51 ` Gilad Ben-Yossef
2012-01-12 14:51 ` Gilad Ben-Yossef
2012-01-12 15:08 ` Peter Zijlstra
2012-01-12 15:08 ` Peter Zijlstra
2012-01-12 15:13 ` Gilad Ben-Yossef
2012-01-12 15:13 ` Gilad Ben-Yossef
2012-01-12 15:08 ` Gilad Ben-Yossef
2012-01-12 15:08 ` Gilad Ben-Yossef
2012-01-12 15:18 ` Peter Zijlstra
2012-01-12 15:18 ` Peter Zijlstra
2012-01-12 15:37 ` Mel Gorman [this message]
2012-01-12 15:37 ` Mel Gorman
2012-01-12 15:52 ` Peter Zijlstra
2012-01-12 15:52 ` Peter Zijlstra
2012-01-12 17:18 ` Mel Gorman
2012-01-12 17:18 ` Mel Gorman
2012-01-12 19:14 ` Gilad Ben-Yossef
2012-01-12 19:14 ` Gilad Ben-Yossef
2012-01-13 20:58 ` Milton Miller
2012-01-15 13:53 ` Gilad Ben-Yossef
2012-01-13 20:58 ` Milton Miller
2012-01-19 16:20 ` Mel Gorman
2012-01-19 21:46 ` Srivatsa S. Bhat
2012-01-19 21:46 ` Srivatsa S. Bhat
2012-01-20 8:48 ` Mel Gorman
2012-01-20 8:48 ` Mel Gorman
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=20120112153712.GL4118@suse.de \
--to=mgorman@suse.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=gilad@benyossef.com \
--cc=gong.chen@intel.com \
--cc=gregkh@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=mszeredi@novell.com \
--cc=paulmck@linux.vnet.ibm.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.