[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