[Cbe-oss-dev] [PATCH 4:6] spufs: fix spu time slice count

Luke Browning lukebr at linux.vnet.ibm.com
Tue May 13 19:08:22 EST 2008


On Tue, 2008-05-13 at 11:54 +0200, Christoph Hellwig wrote:
> On Mon, May 12, 2008 at 02:37:15PM +0000, Luke Browning wrote:
> > Fix spu time slice count
> > 
> > An spu context shouldn't get an extra tick if the time slice code 
> > couldn't find something else to run.
> 
> Well, we still give it the extrace slice when it's actually running,
> and that's intended because no one else would use it otherwise.  

yes.

> What
> your code does is to not give it another slice when it's not running.

yes.  For example, if the ts count is 2 and the context is not running,
then the count is decremented to 1 and we try to find another context to
run.  If we don't, we leave the current context loaded, but we don't
increment the count to 2.  We leave it at 1.  

I don't think it should get a free tick in this case.  

> 
> But in the case where you don't add 1 to that now simply means we'll
> get an unsigned overflow instead when the next scheduler tick happens,
> I don't think that's a good idea either.

I don't see how it could go negative.  we decrement it and if we decided
to let it run longer and the count is zero, we increment it.  It is
never left loaded with a count of zero.

> 
> We probably want to simply unload an idle context when it's time slice
> runs out even if no one is waiting for the resouce so that idle contexts
> don't remain on the spu forever.  On the other hand that would have
> adverse effect when a context performs a ppu assisted library call just
> before the end of it's time slice.

agreed.  we don't want to do this.  we need to continue to support
lazily loaded contexts for performance reasons.

Luke




More information about the cbe-oss-dev mailing list