Rescheduling Interrupts, Tweaking the Scheduler, and bug #177895

[Colin Ian King]

Hi all,

Some apps on duo core machines seem to be generating a lot of kernel
wakeups (for example amarok during mp3 playback) which in turn generates
a lot of "Rescheduling Interrupts" as the scheduler tries to re-balance
core useage. 

A lot of these rescheduling interrupts seem legitimate wake-ups, for
example amarok waking up the 2nd core to make X re-render on one core
while another core busy doing mp3 decode and playback. However the
rescheduling interrupts do look very high on an nearly idle system (e.g.
just running amarok!) when examining a running system with tools such as
powertop.

Alessio has been helpful to find an upstream patch that reduces the
heavy handed rescheduling interrupts when the system is idle on a multi
core system. namely upstream commit
33b0c4217dcd67b788318c3192a2912b530e4eef which tweaks the multi-core
scheduler intialiser flags in include/linux/topology.h to be less
aggressive for IDLE wake ups.

With the fix, we do see a reduction in rescheduling interrupts - that
is, sleeping cores are woken up less by kernel IPI events, however the
CPU C0..C3 residency does change:

		"Fixed" Kernel		Current Kernel
Rescheduling	   
Interrupts/sec	~210-220		~240-250

C0 residency	37%			23%		
C1   ""		 0%			0%	
C2   ""		 0%			0%
C3   ""		63%			28%

Power (Watts)	30.1			27.4

Figures were obtained from powertop running for 8 minutes with average
of 10 second samples.

So... it appears that reducing the "Rescheduling Interrupts" by tweaking
the current scheduler reduces the overall time the processor core is in
the lowest C3 state, and increases the busy C0 state residency, hence
increasing the overall power usage.

With this in mind, I think I will no longer pursue any more fixes to the
scheduler to reduced the "Scheduling Interrupts" as it is detrimental to
power consumption for laptop users et al.

There are a heap of other more significant changes upstream in the
scheduler which may improve things generally but they are far too
intrusive to make so late in the Hardy release cycle.

I will therefore close bug 177895 as "Won't Fix" - and add some notes to
explain why.

Is this OK?

Colin