[Cbe-oss-dev] spusched: timeslicing

Benjamin Herrenschmidt benh at kernel.crashing.org
Sun Apr 8 07:08:43 EST 2007


On Sat, 2007-04-07 at 08:18 -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.

The problem of this approach is that having a timer constantly ticking
at 100HZ per BE or per SPU will defeat CPU idle power management among
other things.

While I agree that we should probably try to have one per-thread (per
PPE thread that is) global timer for SPE scheduling, we should also try
to be smart as to not actually fire it off if no scheduling is required
(for example, here is no contention, nobody is waiting on the run queue,
or simply no SPE context is running, whatever is best...)

Cheers,
Ben.





More information about the cbe-oss-dev mailing list