From: Nathan Lynch <ntl@pobox.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, linuxppc-dev@ozlabs.org, Paul Jackson <pj@sgi.com>,
ak@suse.com, linux-kernel@vger.kernel.org
Subject: Re: Fw: 2.6.16 crashes when running numastat on p575
Date: Mon, 3 Apr 2006 13:01:31 -0500 [thread overview]
Message-ID: <20060403180131.GD25663@localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0604031039560.20648@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
>
> On Mon, 3 Apr 2006, Nathan Lynch wrote:
>
> > In this case, disabling preempt around the for_each_online_cpu loop
> > would prevent any cpu from going down in the meantime. But since this
> > function doesn't look like it's a hot path, and we're potentially
> > traversing lots of zones and cpus, lock_cpu_hotplug might be preferable.
> >
> > As Paul noted, the fix as it stands isn't adequate.
>
> There are many other for_each_*_cpu loops in the kernel that do not have
> any of the instrumentation you suggest. I suggest you come up with a
> general solution and then go through all of them and fix this. Please be
> aware that many of these loops are performance critical.
But this one isn't, right?
And I'm afraid there's a misunderstanding here -- only
for_each_online_cpu (or accessing the cpu online map in general) has
such restrictions -- for_each_possible_cpu doesn't require any locking
or preempt tricks since cpu_possible_map must not change after boot.
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <ntl@pobox.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Paul Jackson <pj@sgi.com>,
akpm@osdl.org, linuxppc-dev@ozlabs.org, ak@suse.com,
linux-kernel@vger.kernel.org
Subject: Re: Fw: 2.6.16 crashes when running numastat on p575
Date: Mon, 3 Apr 2006 13:01:31 -0500 [thread overview]
Message-ID: <20060403180131.GD25663@localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0604031039560.20648@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
>
> On Mon, 3 Apr 2006, Nathan Lynch wrote:
>
> > In this case, disabling preempt around the for_each_online_cpu loop
> > would prevent any cpu from going down in the meantime. But since this
> > function doesn't look like it's a hot path, and we're potentially
> > traversing lots of zones and cpus, lock_cpu_hotplug might be preferable.
> >
> > As Paul noted, the fix as it stands isn't adequate.
>
> There are many other for_each_*_cpu loops in the kernel that do not have
> any of the instrumentation you suggest. I suggest you come up with a
> general solution and then go through all of them and fix this. Please be
> aware that many of these loops are performance critical.
But this one isn't, right?
And I'm afraid there's a misunderstanding here -- only
for_each_online_cpu (or accessing the cpu online map in general) has
such restrictions -- for_each_possible_cpu doesn't require any locking
or preempt tricks since cpu_possible_map must not change after boot.
next prev parent reply other threads:[~2006-04-03 18:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060402213216.2e61b74e.akpm@osdl.org>
2006-04-03 5:12 ` Fw: 2.6.16 crashes when running numastat on p575 Christoph Lameter
2006-04-03 5:12 ` Christoph Lameter
2006-04-03 5:15 ` Paul Jackson
2006-04-03 5:15 ` Paul Jackson
2006-04-03 5:25 ` Christoph Lameter
2006-04-03 5:25 ` Christoph Lameter
2006-04-03 6:43 ` Paul Jackson
2006-04-03 6:43 ` Paul Jackson
2006-04-03 14:10 ` Nathan Lynch
2006-04-03 14:10 ` Nathan Lynch
2006-04-03 17:42 ` Christoph Lameter
2006-04-03 17:42 ` Christoph Lameter
2006-04-03 18:01 ` Nathan Lynch [this message]
2006-04-03 18:01 ` Nathan Lynch
2006-04-03 18:08 ` Christoph Lameter
2006-04-03 18:08 ` Christoph Lameter
2006-04-03 21:18 ` Andrew Morton
2006-04-03 21:18 ` Andrew Morton
2006-04-04 0:25 ` Paul Jackson
2006-04-04 0:25 ` Paul Jackson
2006-04-03 11:49 ` Andi Kleen
2006-04-03 11:49 ` Andi Kleen
2006-04-03 14:18 ` Nathan Lynch
2006-04-03 14:18 ` Nathan Lynch
2006-04-03 8:09 ` Sonny Rao
2006-04-03 8:09 ` Sonny Rao
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=20060403180131.GD25663@localdomain \
--to=ntl@pobox.com \
--cc=ak@suse.com \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=pj@sgi.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.