[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