From: Andrew Morton <akpm@linux-foundation.org>
To: Bob Nelson <rrnelson@linux.vnet.ibm.com>
Cc: linuxppc <linuxppc-dev@ozlabs.org>,
Maynard Johnson <maynardj@linux.vnet.ibm.com>,
Arnd Bergmann <arndb@de.ibm.com>,
oprofile <oprofile-list@lists.sourceforge.net>,
Philippe Elie <phil.el@wanadoo.fr>
Subject: Re: [PATCH 1/2] OProfile - Enable SPU switch notification to detect currently active SPU tasks - update
Date: Fri, 20 Jul 2007 13:02:41 -0700 [thread overview]
Message-ID: <20070720130241.176c50a5.akpm@linux-foundation.org> (raw)
In-Reply-To: <200707201424.07292.rrnelson@linux.vnet.ibm.com>
On Fri, 20 Jul 2007 14:24:07 -0500
Bob Nelson <rrnelson@linux.vnet.ibm.com> wrote:
> From: Maynard Johnson <mpjohn@us.ibm.com>
>
> This patch adds to the capability of spu_switch_event_register so that
> the caller is also notified of currently active SPU tasks.
> Exports spu_switch_event_register and spu_switch_event_unregister so
> that OProfile can get access to the notifications provided.
>
> Signed-off-by: Maynard Johnson <mpjohn@us.ibm.com>
> Signed-off-by: Carl Love <carll@us.ibm.com>
> Signed-off-by: Bob Nelson <rrnelson@us.ibm.com>
> Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> Acked-by: Paul Mackerras <paulus@samba.org>
>
> ---
>
> We would like this patch included in -mm and 2.6.23
>
> Changed "for (node = 0; node < MAX_NUMNODES; node++)" loop to
> for_each_online_node(node).
> Added comment to memory barrier.
> Better info in changelog.
here it is:
--- a/arch/powerpc/platforms/cell/spufs/sched.c~oprofile-enable-spu-switch-notification-to-detect-currently-active-spu-tasks-update
+++ a/arch/powerpc/platforms/cell/spufs/sched.c
@@ -220,13 +220,14 @@ static void notify_spus_active(void)
* When the awakened processes see their "notify_active" flag is set,
* they will call spu_switch_notify();
*/
- for (node = 0; node < MAX_NUMNODES; node++) {
+ for_each_online_node(node) {
struct spu *spu;
mutex_lock(&spu_prio->active_mutex[node]);
list_for_each_entry(spu, &spu_prio->active_list[node], list) {
struct spu_context *ctx = spu->ctx;
set_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
- mb();
+ mb(); /* make sure any tasks woken up below */
+ /* can see the bit(s) set above */
wake_up_all(&ctx->stop_wq);
}
mutex_unlock(&spu_prio->active_mutex[node]);
_
I still wonder about that barrier. At the least it should be smp_mb().
But aren't our set_bit() semantics _alone_ sufficient to make this barrier
unneeded?
If it _is_ possible for the effects of a set_bit() to not be visible to a
woken-up thread then I suspect we'll have nasty little problems in quite a
few places. Maybe wake_up() should itself have a barrier to prevent such
things?
Doing that would be a documentation-only change, I suspect, given that the
current implementation of wake_up() starts out with a spin_lock_irqsave().
next prev parent reply other threads:[~2007-07-20 20:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 19:24 [PATCH 1/2] OProfile - Enable SPU switch notification to detect currently active SPU tasks - update Bob Nelson
2007-07-20 20:02 ` Andrew Morton [this message]
2007-07-20 19:58 ` Arnd Bergmann
2007-07-22 1:37 ` Paul Mackerras
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=20070720130241.176c50a5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=arndb@de.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=maynardj@linux.vnet.ibm.com \
--cc=oprofile-list@lists.sourceforge.net \
--cc=phil.el@wanadoo.fr \
--cc=rrnelson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).