Issues with Patch: "sched: Improve latencies and throughput"

Issues with Patch: "sched: Improve latencies and throughput"

[Michael Grzeschik]

We are using an arm mx31 embedded cpu with the v2.6.34 Kernelrelease and
realized some issues with the scheduling behaviour the patch "sched:
Improve latencies and throughput" [1] by Mike Galbraith introduced to
the kernel.

When we used the alsa utility aplay to pipe some audio through an
usbaudio device and put some scheduling overhead on the device, the
amount of underruns, due to the not fast enough refilled ring buffer,
was noticable increased with that patch [1] applied. Until we reverse
applied the patch the amount of underruns was appreciable lower.

That in fact is the opposite behaviour to its actual meaning.

[1] 0ec9fab3d186d9cbb00c0f694d4a260d07c198d9

mgr

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Issues with Patch: "sched: Improve latencies and throughput"

[Mike Galbraith]

On Thu, 2010-04-01 at 00:31 +0200, Michael Grzeschik wrote:
> We are using an arm mx31 embedded cpu with the v2.6.34 Kernelrelease and
> realized some issues with the scheduling behaviour the patch "sched:
> Improve latencies and throughput" [1] by Mike Galbraith introduced to
> the kernel.
> 
> When we used the alsa utility aplay to pipe some audio through an
> usbaudio device and put some scheduling overhead on the device, the
> amount of underruns, due to the not fast enough refilled ring buffer,
> was noticable increased with that patch [1] applied. Until we reverse
> applied the patch the amount of underruns was appreciable lower.

Testcase?

> That in fact is the opposite behaviour to its actual meaning.

Not necessarily.  NEXT_BUDDY can increase latency for waiters, as can
_not_ pulling a waiter to an idle CPU. 


> [1] 0ec9fab3d186d9cbb00c0f694d4a260d07c198d9
> 
> mgr

	-Mike

Re: Issues with Patch: "sched: Improve latencies and throughput"

[Michael Grzeschik]

On Thu, Apr 01, 2010 at 07:49:46AM +0200, Mike Galbraith wrote:
> On Thu, 2010-04-01 at 00:31 +0200, Michael Grzeschik wrote:
> > We are using an arm mx31 embedded cpu with the v2.6.34 Kernelrelease and
> > realized some issues with the scheduling behaviour the patch "sched:
> > Improve latencies and throughput" [1] by Mike Galbraith introduced to
> > the kernel.
> > 
> > When we used the alsa utility aplay to pipe some audio through an
> > usbaudio device and put some scheduling overhead on the device, the
> > amount of underruns, due to the not fast enough refilled ring buffer,
> > was noticable increased with that patch [1] applied. Until we reverse
> > applied the patch the amount of underruns was appreciable lower.
> 
> Testcase?

What we did was:

# Copy some audiofile to /dev/shm
$ cp audiofile.wav /dev/shm

# Play that file with aplay in background
$ aplay /dev/shm/auduifile.wav &

# Put some scheduling load on the system
$ hackbench 6

We did use this on an MX31 from Freescale running with about 500 MHz and
the generic usbaudio driver to play the audio throgh an C-Media USB
audiodongle.

Expected results with that patch:

underrun!!! (at least 323.946 ms long) < -- aplay
underrun!!! (at least 59.477 ms long)  < --     "
underrun!!! (at least 194.873 ms long) < --     "
Time: 7.048                            < -- hackbench
Time: 6.841                            < --     "
underrun!!! (at least 115.456 ms long) < -- aplay
underrun!!! (at least 37.849 ms long)  < --     "
underrun!!! (at least 588.637 ms long) < --     "
Time: 7.23                             < -- hackbench

results without the patch:

Time: 3.728                            < -- hackbench
underrun!!! (at least 58.557 ms long)  < -- aplay
Time: 3.771                            < -- hackbench
underrun!!! (at least 97.538 ms long)  < -- aplay
Time: 3.732                            < -- hackbench
Time: 3.630                            < --  ....
Time: 3.636
Time: 3.643

Thanks,
mgr

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Issues with Patch: "sched: Improve latencies and throughput"

[Mike Galbraith]

On Thu, 2010-04-01 at 10:43 +0200, Michael Grzeschik wrote:
> On Thu, Apr 01, 2010 at 07:49:46AM +0200, Mike Galbraith wrote:
> > On Thu, 2010-04-01 at 00:31 +0200, Michael Grzeschik wrote:
> > > We are using an arm mx31 embedded cpu with the v2.6.34 Kernelrelease and
> > > realized some issues with the scheduling behaviour the patch "sched:
> > > Improve latencies and throughput" [1] by Mike Galbraith introduced to
> > > the kernel.
> > > 
> > > When we used the alsa utility aplay to pipe some audio through an
> > > usbaudio device and put some scheduling overhead on the device, the
> > > amount of underruns, due to the not fast enough refilled ring buffer,
> > > was noticable increased with that patch [1] applied. Until we reverse
> > > applied the patch the amount of underruns was appreciable lower.
> > 
> > Testcase?
> 
> What we did was:
> 
> # Copy some audiofile to /dev/shm
> $ cp audiofile.wav /dev/shm
> 
> # Play that file with aplay in background
> $ aplay /dev/shm/auduifile.wav &
> 
> # Put some scheduling load on the system
> $ hackbench 6
> 
> We did use this on an MX31 from Freescale running with about 500 MHz and
> the generic usbaudio driver to play the audio throgh an C-Media USB
> audiodongle.

Hm.  I don't _think_ you've demonstrated a clear problem yet.

Q: how much CPU is aplay routinely using on this platform?

	-Mike