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

Previous thread: [git pull] x86 platform driver tree by Matthew Garrett on Wednesday, March 31, 2010 - 2:25 pm. (1 message)

Next thread: RFC: Ideal Adaptive Spinning Conditions by Darren Hart on Wednesday, March 31, 2010 - 4:21 pm. (24 messages)
From: Michael Grzeschik
Date: Wednesday, March 31, 2010 - 3:31 pm

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

From: Mike Galbraith
Date: Wednesday, March 31, 2010 - 10:49 pm

Not necessarily.  NEXT_BUDDY can increase latency for waiters, as can

	-Mike

--

From: Michael Grzeschik
Date: Thursday, April 1, 2010 - 1:43 am

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

From: Mike Galbraith
Date: Thursday, April 1, 2010 - 12:35 pm

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

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

	-Mike

--

Previous thread: [git pull] x86 platform driver tree by Matthew Garrett on Wednesday, March 31, 2010 - 2:25 pm. (1 message)

Next thread: RFC: Ideal Adaptive Spinning Conditions by Darren Hart on Wednesday, March 31, 2010 - 4:21 pm. (24 messages)