Implement THREAD_PRIORITY_TIME_CRITICAL

Con Kolivas kernel at kolivas.org
Tue Apr 4 09:36:06 CDT 2006


On Wednesday 05 April 2006 00:34, Andreas Mohr wrote:
> 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...

Andi just out of interest, how does normal scheduling on current ck 
(2.6.16-ck3) perform with this?

Cheers,
Con



More information about the wine-devel mailing list