[Cbe-oss-dev] PATCH [4/7] decouple spu scheduler from spufs_spu_run [asynchronous scheduling]

[Luke Browning]

On Fri, 2007-11-23 at 15:41 +0100, Christoph Hellwig wrote:
> The dma test failures were caused by the removal of the signal_pending
> check in spu_run_fini.  By putting it back the testsuite now passes
> perfectly.
> 
> 
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> 
> Index: linux-2.6/arch/powerpc/platforms/cell/spufs/run.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/run.c	2007-11-23 14:34:09.000000000 +0100
> +++ linux-2.6/arch/powerpc/platforms/cell/spufs/run.c	2007-11-23 14:34:27.000000000 +0100
> @@ -226,15 +226,15 @@
>  static int spu_run_fini(struct spu_context *ctx, u32 *npc,
>  			       u32 *status)
>  {
> -	int ret = 0;
> -
>  	*status = ctx->ops->status_read(ctx);
>  	*npc = ctx->ops->npc_read(ctx);
> 
>  	spuctx_switch_state(ctx, SPU_UTIL_IDLE_LOADED);
>  	spu_release(ctx);
> 
> -	return ret;
> +	if (signal_pending(current))
> +		return -ERESTARTSYS;
> +	return 0;
>  }
> 
>  static int spu_reacquire_runnable(struct spu_context *ctx, u32 *npc,

I am a little puzzled by this failure.  The only difference that I could
see in my version of the code is that the return code would be different
if a signal was pending and you had a concurrent event like an spe error
or library call.  I moved the signal_pending check to the first level.

The loop looks like:

do {
	spufs_wait()

	process kernel callbacks --> break on error

	process class 0 & 1 --> break on error

	if (library callback) 
		break;

	if (signal_pending) {
		ret = -ERESTARTSYS;
		break;
	}

} while (1);

spu_run_fini();

I wouldn't think that this would make a difference as we don't guarantee
the order of delivery of multiple events.   

Note that there is a bug related to signals that I fixed in Patch [6/7]
but it only happens if the spes are over committed. 

Luke