All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maynard Johnson <maynardj@us.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Arnd Bergmann <arnd.bergmann@de.ibm.com>,
	linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Cbe-oss-dev] [PATCH] Cell SPU task notification
Date: Wed, 17 Jan 2007 09:56:12 -0600	[thread overview]
Message-ID: <45AE471C.8040909@us.ibm.com> (raw)
In-Reply-To: <20070117003018.GA17955@lst.de>

Christoph Hellwig wrote:

>Index: linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c
>===================================================================
>--- linux-2.6.19-rc6-arnd1+patches.orig/arch/powerpc/platforms/cell/spufs/sched.c	2006-12-04 10:56:04.730698720 -0600
>+++ linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c	2007-01-15 16:22:31.808461448 -0600
>@@ -84,15 +84,42 @@
> 			    ctx ? ctx->object_id : 0, spu);
> }
>
>+static void notify_spus_active(void)
>+{
>+       int node;
>+	/* Wake up the active spu_contexts. When the awakened processes
>+	 * sees their notify_active flag is set, they will call
>+	 * spu_notify_already_active().
>+	 */
>+	for (node = 0; node < MAX_NUMNODES; node++) {
>+		struct spu *spu;
>+		mutex_lock(&spu_prio->active_mutex[node]);
>+                list_for_each_entry(spu, &spu_prio->active_list[node], list) {
>
>	You seem to have some issues with tabs vs spaces for indentation
>	here.
>  
>
fixed

>+			struct spu_context *ctx = spu->ctx;
>+			spu->notify_active = 1;
>
>
>	Please make this a bit in the sched_flags field that's added in
>	the scheduler patch series I sent out.
>  
>
I haven't seen that the scheduler patch series got applied yet.  This 
Cell spu task notification patch is a pre-req for OProfile development 
to support profiling SPUs.   When the scheduler patch gets applied to a 
kernel version that fits our needs for our OProfile development, I don't 
see any problem in using the sched_flags field instead of notify_active.

>+			wake_up_all(&ctx->stop_wq);
>+			smp_wmb();
>+		}
>+                mutex_unlock(&spu_prio->active_mutex[node]);
>+	}
>+	yield();
>+}
>
>	Why do you add the yield() here?  yield is pretty much a sign
>	for a bug
>  
>
Yes, the yield() and the memory barriers were leftovers from an earlier 
ill-conceived attempt at solving this problem.  They should have been 
removed.  They're gone now.

>+void spu_notify_already_active(struct spu_context *ctx)
>+{
>+	struct spu *spu = ctx->spu;
>+	if (!spu)
>+		return;
>+	spu_switch_notify(spu, ctx);
>+}
>
>	Please just call spu_switch_notify directly from the only
>  
>
I hesitated doing this since it would entail changing spu_switch_notify 
from being static to non-static.  I'd like to get Arnd's opinion on this 
question before going ahead and making such a change.

>	caller.  Also the check for ctx->spu beeing there is not
>	required if you look a the caller.
>
>
> 	*stat = ctx->ops->status_read(ctx);
>-	if (ctx->state != SPU_STATE_RUNNABLE)
>-		return 1;
>+	smp_rmb();
>  
>
>
>	What do you need the barrier for here?
>  
>
Removed.

WARNING: multiple messages have this Message-ID (diff)
From: Maynard Johnson <maynardj@us.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: cbe-oss-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org, Arnd Bergmann <arnd.bergmann@de.ibm.com>
Subject: Re: [Cbe-oss-dev] [PATCH] Cell SPU task notification
Date: Wed, 17 Jan 2007 09:56:12 -0600	[thread overview]
Message-ID: <45AE471C.8040909@us.ibm.com> (raw)
In-Reply-To: <20070117003018.GA17955@lst.de>

Christoph Hellwig wrote:

>Index: linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c
>===================================================================
>--- linux-2.6.19-rc6-arnd1+patches.orig/arch/powerpc/platforms/cell/spufs/sched.c	2006-12-04 10:56:04.730698720 -0600
>+++ linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c	2007-01-15 16:22:31.808461448 -0600
>@@ -84,15 +84,42 @@
> 			    ctx ? ctx->object_id : 0, spu);
> }
>
>+static void notify_spus_active(void)
>+{
>+       int node;
>+	/* Wake up the active spu_contexts. When the awakened processes
>+	 * sees their notify_active flag is set, they will call
>+	 * spu_notify_already_active().
>+	 */
>+	for (node = 0; node < MAX_NUMNODES; node++) {
>+		struct spu *spu;
>+		mutex_lock(&spu_prio->active_mutex[node]);
>+                list_for_each_entry(spu, &spu_prio->active_list[node], list) {
>
>	You seem to have some issues with tabs vs spaces for indentation
>	here.
>  
>
fixed

>+			struct spu_context *ctx = spu->ctx;
>+			spu->notify_active = 1;
>
>
>	Please make this a bit in the sched_flags field that's added in
>	the scheduler patch series I sent out.
>  
>
I haven't seen that the scheduler patch series got applied yet.  This 
Cell spu task notification patch is a pre-req for OProfile development 
to support profiling SPUs.   When the scheduler patch gets applied to a 
kernel version that fits our needs for our OProfile development, I don't 
see any problem in using the sched_flags field instead of notify_active.

>+			wake_up_all(&ctx->stop_wq);
>+			smp_wmb();
>+		}
>+                mutex_unlock(&spu_prio->active_mutex[node]);
>+	}
>+	yield();
>+}
>
>	Why do you add the yield() here?  yield is pretty much a sign
>	for a bug
>  
>
Yes, the yield() and the memory barriers were leftovers from an earlier 
ill-conceived attempt at solving this problem.  They should have been 
removed.  They're gone now.

>+void spu_notify_already_active(struct spu_context *ctx)
>+{
>+	struct spu *spu = ctx->spu;
>+	if (!spu)
>+		return;
>+	spu_switch_notify(spu, ctx);
>+}
>
>	Please just call spu_switch_notify directly from the only
>  
>
I hesitated doing this since it would entail changing spu_switch_notify 
from being static to non-static.  I'd like to get Arnd's opinion on this 
question before going ahead and making such a change.

>	caller.  Also the check for ctx->spu beeing there is not
>	required if you look a the caller.
>
>
> 	*stat = ctx->ops->status_read(ctx);
>-	if (ctx->state != SPU_STATE_RUNNABLE)
>-		return 1;
>+	smp_rmb();
>  
>
>
>	What do you need the barrier for here?
>  
>
Removed.



  reply	other threads:[~2007-01-17 15:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-12 22:03 [PATCH] Cell SPU task notification Maynard Johnson
2007-01-15  2:07 ` Michael Ellerman
2007-01-15  2:07   ` Michael Ellerman
2007-01-15 20:21   ` Maynard Johnson
2007-01-15 20:21     ` Maynard Johnson
2007-01-15 22:39   ` [PATCH] Cell SPU task notification -- updated patch: #1 Maynard Johnson
2007-01-15 22:39     ` Maynard Johnson
2007-01-17  0:30 ` [Cbe-oss-dev] [PATCH] Cell SPU task notification Christoph Hellwig
2007-01-17  0:30   ` Christoph Hellwig
2007-01-17 15:56   ` Maynard Johnson [this message]
2007-01-17 15:56     ` Maynard Johnson
2007-01-19  3:19     ` Christoph Hellwig
2007-01-19  3:19       ` Christoph Hellwig
2007-01-26 22:39     ` [Cbe-oss-dev] [PATCH] Cell SPU task notification - repost of patch with updates Maynard Johnson
2007-01-26 22:39       ` Maynard Johnson

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=45AE471C.8040909@us.ibm.com \
    --to=maynardj@us.ibm.com \
    --cc=arnd.bergmann@de.ibm.com \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    /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.