Implement THREAD_PRIORITY_TIME_CRITICAL

[Con Kolivas]

On Wednesday 05 April 2006 00:49, Mike Hearn wrote:
> >>> 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 don't want to do that! If there are other [robust] solutions I'm all
> ears. The patch did not take long to write, I am not attached to it. I
> am just having problems understanding what the alternatives are or where
> to start.
>
> >>> 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?
>
> Sure, it's decompressing now. Will be a while before I can report, I
> have an old computer so it will take some time to build.

Ok. This is not a shot in the dark by the way because you mentioned pipes and 
I had a quick look at the wine sound code. I committed some changes to the 
cpu scheduler in 2.6.17-rc1 that change the way it views sleeping on pipes...

> So in this case either the CPU time goes way high when the 3D scene
> first appears, or maybe my 3D driver (nvidia) is not allowing
> pre-emption enough.

So bas soon as cpu usage is high the audio stutters. This isn't about in 
kernel preemption, but basic scheduling latency going wrong for audio.

> I guess I'm uneasy about this idea of keeping cpu time low, even for
> threads we control, because how do we debug it? How does one monitor a
> scheduler anyway? Maybe the problem is our audio thread is using too
> much cpu time - ok, how do we measure that? How much is too much? What
> threshold do we have to beat to get scheduling latency low enough to
> work properly? How do we figure out if the scheduler is doing what we
> think it's doing? What if it is a driver problem? This all seems very
> opaque to me.

I suspect you're missing my point. I don't want you to go policing cpu usage 
of threads and watching the scheduler to make sure you're not tripping up or 
whatever. I only want to see "generic goodness" :) I don't want to see audio 
threads mixed up with the the same things using up lots of cpu or drawing 3d 
- just check the original xmms code and you'll see how not to do it. Better 
yet, don't look at it. I had a very cursory look at the sound code in wine 
and it seems sane on first inspection. Let's get some feedback on the kernel 
change now. Sleep might take me before we can continue this though.

Cheers,
Con