Con Kolivas kernel at
Mon Apr 3 21:14:37 CDT 2006

On Tue, 4 Apr 2006 01:47 am, Andreas Mohr wrote:
> Hi,
> [sneaked in another CC, JFYI ;]

Oh hi! This is the first time this thread has been brought to my attention.

> On Mon, Apr 03, 2006 at 04:29:43PM +0100, Mike Hearn wrote:
> > And even then, SCHED_ISO is a long way off and may never be merged.
> > Waiting for it wouldn't be helping users today, which is a bad thing
> > IMHO.
> I don't think SCHED_ISO is necessarily a long way off. Recently there has
> been more activity in getting scheduler improvements into mainline, so some
> form of SCHED_ISO class might appear soon.

I've had a whole read of this thread online now that I've found it and there 
are a number of things that I should mention since people seem quite happy to 
talk around my code :)

SCHED_ISO is a stable, mostly realtime solution for normal users. The one 
scenario that SCHED_FIFO was required _over_ the capabilities of SCHED_ISO is 
only professional audio sampling/capture work where one process may require 
almost 100% cpu for bursts of many seconds. Therefore for audio playback, 
SCHED_ISO is more than qualified.

While I'm pleased that SCHED_ISO fixes the problem for many people on this 
thread, I have to tell you that it is _not_ the solution to your problem for 
a number of reasons. My motivation for creating this scheduling class was for 
transparent realtime performance to be attainable for an ordinary desktop 
user without their knowledge or previous setup. The reason is that the 
current system for giving realtime privileges to ordinary users is 
complicated and not set up properly by hardly any distributions. This is the 
real time rlimits capabilites which is already in the kernel.

I'm disappointed yet again that there is no simple way for something as low 
cpu using as audio on wine cannot get low enough latency for ordinary 
playback without realtime scheduling. I've mentioned this on the mailing list 
before. The fact that the cpu scheduler is going to completely reorder 
processes in the order it sees fit, based mostly on cpu usage and wakeups 
means that unless there is some form of blocking between audio and the heavy 
cpu using game, there will be no guarantee that audio will be scheduled in 
preference to the game. This is obviously what you're seeing.

What strikes me is that people are very happy to think that the kernel is 
going to fix this problem. I have to tell you there will be no more 
infrastructure put into the kernel anytime soon to help you here. Since I 
have the displeasure of having to reiterate this to you I should probably 
offer some useful suggestions if I could think of some...

I do not believe you are going to need real time scheduling to get audio to 
work properly. This really is overkill in my opinion. However if you really 
want to go down this path you need to use the kernel infrastructure that is 
already in place. The realtime rlimits is there and works. Getting modern 
distributions to have it set up by default properly is the first challenge. I 
have not investigated to see who has done this, but if they are not then 
pinging the distribution maintainers or even helping them set it up is the 
thing to do here. Providing walk-throughs on setting it up (until the distros 
catch up) and using the system from within wine seems appropriate.

Audio playback and decoding should not really use much cpu. Processes that do 
not use much cpu are given preferential low latency in the kernel without 
changing scheduling class. The way to ensure that audio playback therefore 
always "wins" over cpu intensive games is to have a separate audio playback 
thread that uses as _little cpu_ as possible. This means it should do just 
the audio playback and do nothing else. Last time I checked the alsa code it 
does queueing/blocking without needing any extra polling. The practice, for 
example, of xmms(1) of checking to see if there's room in the queue every 
10ms is ancient and the wrong way to code audio.

Lastly, and this is not a comment about wine but all programming in general, 
multithreading cannot be left up to chance. More than ever with multiple cpu 
cores, logical cores, threads and an out-of-queued-order cpu scheduler, 
threads _must_ block on each other as much as possible. It cannot be left up 
to chance if they depend on each other. Use of sched_yield for example which 
just gives up the cpu for a random duration in the hope another thread gets 
scheduled meantime is basically wrong for anything but realtime tasks of the 
same priority. It has no place in modern code. All that will end up happening 
is processes will wake up and use cpu (spinning) for nothing decreasing 
throughput, and latencies will blow out. Again I'm not saying wine does this, 
but feel obliged to say this whenever the cpu scheduler is blamed for wrong 
"ordering" of tasks.

Hope this helps


More information about the wine-devel mailing list