[Cbe-oss-dev] spusched: timeslicing

[Luke Browning]

On Tue, 2007-04-10 at 14:12 +0200, Christoph Hellwig wrote:
> On Sat, Apr 07, 2007 at 08:18:24AM -0300, Luke Browning wrote:
> > Hi Christoph,
> > 
> > The current code starts and stops a timer each time a context is started
> > and stopped. This is a relatively heavy operation that disables
> > interrupts and takes a lock each time an spu is started or stopped, and
> > the behavior is application dependent. An application that pages faults
> > a lot or invokes a lot of remote system calls could generate thousands
> > of timer requests. I think that we should use a more traditional
> > approach here with a per BE or SPU timer that ticks independently of the
> > SPU at a steady rate. Say 10 times a second. You would need to time
> > stamp spu dispatch cycles and accrue spu utilization in the context
> > structure. The time slice code would ue this information along with
> > runqueue state to determine whether a context switch should occur.  Time
> > slicing code would be the same for SCHED_RR and SCHED_OTHER.
> 
> This definitively has advantages, but it also has the downside that
> we'd still have ticks when spu load is low.  I've long put onto my
> todo list to play around with a scheme of the dynamic ticks scheduler
> we recently merged for the cpu side.

It should perform a lot better than the current approach which is a
really good testcase for timers.  It might also solve the simulator
problem which I believe is related to timers.  I am not sure what the
problem is there, maybe, the new soft interrupt mechanism is not
enabling interrupts in some path, but what I saw was all timer
activation stopped, even the system timer.  

It should be possible to take advantage of the dynamic tick code in the
mainline scheduler if you can provide this function as an extension of
the system timer. The old unix routine, delay(), was based on the system
timer.  It performed the wakeup in the context of the system timer.  Not
sure if linux has a sleep / wakeup mechanism built on top of the system
timer, but if it did it would solve this problem.  There are also
variations on this theme where a timer can be scheduled that does not
generate any extra clock interrupts. It uses the interrupt associated
with the system timer to guarantee that an interrupt will eventually be
scheduled.  The clock code just processes N timer entries.  There is a
lot of code in the system that could take advantage of such a mechanism
as most code sets timers in the range of a second or a minute and it
doesn't matter if it goes off a little bit late. If you structured the
code in this way it would also have the advantage of not defeating the
idle power management code, since the cpu has to wake up to process the
system timer.  Seems like a win all the way around.

Luke