[Cbe-oss-dev] [PATCH 2/2] [POWERPC] spufs: fix invalid scheduling of forgotten contexts

Luke Browning lukebr at linux.vnet.ibm.com
Fri Feb 29 12:38:24 EST 2008


On Thu, 2008-02-28 at 10:51 +1100, Jeremy Kerr wrote:

> +++ b/arch/powerpc/platforms/cell/spufs/context.c
> @@ -109,13 +109,12 @@ void spu_forget(struct spu_context *ctx)
> 
>  	/*
>  	 * This is basically an open-coded spu_acquire_saved, except that
> -	 * we don't acquire the state mutex interruptible.
> +	 * we don't acquire the state mutex interruptible, and we don't
> +	 * want this context to be rescheduled on release.
>  	 */
>  	mutex_lock(&ctx->state_mutex);
> -	if (ctx->state != SPU_STATE_SAVED) {
> -		set_bit(SPU_SCHED_WAS_ACTIVE, &ctx->sched_flags);
> +	if (ctx->state != SPU_STATE_SAVED)
>  		spu_deactivate(ctx);
> -	}
> 
>  	mm = ctx->owner;
>  	ctx->owner = NULL;

I think that you should unconditionally call spu_deactivate(), because
the context may be on the runqueue.  In that case, its state is
SPU_STATE_SAVED.  Also, we need to improve spu_deactivate(), so that it
removes elements from the runqueue, not just unloads them.

The way I did this in my gang scheduling prototype is:

void spu_deactivate(struct spu_gang *gang)
{
        spu_context_nospu_trace(spu_deactivate__enter, gang);
        set_bit(SPU_SCHED_DEACTIVATED, &gang->sched_flags);
        __spu_deactivate(gang, 1, MAX_PRIO);
        spu_del_from_rq(gang);
}

The routine __spu_deactivate() is just concerned with unloading and finding
another gang (ctx in your case) to run.

Cheers,
Luke




More information about the cbe-oss-dev mailing list