All of lore.kernel.org
 help / color / mirror / Atom feed
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().

  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 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.