kernel at kolivas.org
Mon Apr 3 21:14:37 CDT 2006
On Tue, 4 Apr 2006 01:47 am, Andreas Mohr wrote:
> [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