Implement THREAD_PRIORITY_TIME_CRITICAL

Andreas Mohr andi at rhlx01.fht-esslingen.de
Tue Apr 4 09:34:10 CDT 2006


Hi,

On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote:
> On Wednesday 05 April 2006 00:06, Mike Hearn wrote:
> > I think for now I shall just maintain this patch out of tree so savvy
> > users can apply it and get glitch-free audio. I have never been
> > convinced by this sacred devotion to avoiding SCHED_FIFO: the
> > restrictions behind it make total sense on a server where you have
> > multiple users who may be untrusted. I doubt most end-users care on a
> > desktop with a readily accessible reset button. A game goes batty and
> > hangs the machine - oh well, hit reset and don't play it again. Problem
> > solved.
> 
> Don't give up now as you will convince everyone else there is no solution and 
> only your patch will make games work. Your attitude is defeatist because 
> you're convinced that real time scheduling is your saviour. I'm trying to 
> help you here, so can you  do me one favour and try 2.6.17-rc1 without any 
> special patches and tell me how it currently performs?

I have the same feeling here.
We have a *small* winealsa (or whatever audio backend you choose) thread that
one would think does *minimal* audio processing, so there really shouldn't be
*any* reason for this to not work, since as said before a thread with minimal
CPU runtime and specific wakeup requirements should get scheduled just
perfectly with a current scheduler mechanism that honours minimal CPU use of a
thread with high-priority wakeup performance.

Since it doesn't seem to work, either Wine's audio thread gets out of hand
and consumes way too much CPU (maybe it gets confused by some weird audio
polling behaviour of a Win32 app) or the current scheduler(s) don't honour
such a thread optimally. Or... the Wine neighbour threads call into weird
system calls that don't behave optimally (i.e. they prevent proper scheduling
by not allowing preemption for larger periods of time).

And this all should work perfectly well with NON-soft-realtime scheduling,
as clearly said before.
Well, in theory, at least...

Andreas



More information about the wine-devel mailing list