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
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 |
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