[Cbe-oss-dev] another context switch question

Luke Browning lukebr at linux.vnet.ibm.com
Wed Sep 12 01:34:08 EST 2007


long spufs_run_spu(struct file *file, struct spu_context *ctx,
                   u32 *npc, u32 *event)
{

	<...>

        do {
                ret = spufs_wait(ctx->stop_wq, spu_stopped(ctx, &status));
                spu = ctx->spu;

spu will be NULL after a context switch.  I suspect that this is not expected
and it should be initialized before the spufs_wait().  I believe the intent is
to identify the spu where the context last ran.  

                if (unlikely(ret))
                        break;

                spuctx_switch_state(ctx, SPUCTX_UTIL_SYSTEM);

                if (unlikely(test_bit(SPU_SCHED_NOTIFY_ACTIVE,
                                      &ctx->sched_flags))) {
                        clear_bit(SPU_SCHED_NOTIFY_ACTIVE, &ctx->sched_flags);
                        if (!(status & SPU_STATUS_STOPPED_BY_STOP)) {
                                spu_switch_notify(spu, ctx);
                                continue;
                        }
                }

More importantly, the context lock is held over spu_switch_notify() meaning
that the context cannot be saved or restored.  I don't think the scheduler 
should be dependent on another module.  We should be able to context switch
out the context during these calls. 

Note that the callout occurs for every stop and context switch and that the 
callout occurs before spe exceptions are handled.  I assume that the handler
is not allowed to read / write the spe register state.  The context may or 
may not be runnable as you can have an event and a context switch occur at 
the same time, so the handler doesn't know how to access the data.  And what 
would it do with the data anyway?  So, I think we should change the code so
that the callout is only made for context switches.  In that case, I would 
move it after processing of the class 0 and 1 interrupts.

Thx,
Luke




More information about the cbe-oss-dev mailing list