Implement THREAD_PRIORITY_TIME_CRITICAL
Con Kolivas
kernel at kolivas.org
Tue Apr 4 08:17:52 CDT 2006
On Tuesday 04 April 2006 22:42, Mike Hearn wrote:
> > 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.
>
> I'm confused about this point. You say the kernel won't be changing
> anytime soon - does this mean you've given up on getting SCHED_ISO into
> the mainline kernels?
It was something I toyed with until the realtime rlimits was put in place.
There's no real need for it now. I support it in -ck because it's convenient
for myself and users. It also depends on my staircase cpu scheduler and would
need a complete rewrite for the mainline scheduler. Since the feature is not
desired in mainline there's not much point me doing that.
> Can we _really_ not expect any support from the
> kernel people here?
No. Again there is no reason an app should require some special kernel hook to
work for something like a game. I _know_ it makes life easier but that's not
the solution or else the kernel would be a complete mess of hooks for all
sorts of applications that would like their own hook to make life easier.
> > 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.
>
> OK. We'd love some alternative, if only because Alexandre seems dead set
> against anything that requires root access, even if that includes not
> running Wine itself as root.
I absolutely agree with him. Even the realtime rlimits is the wrong approach
as it effectively gives the same sort of scheduling rights to starve a system
that only root normally has.
> > Audio playback and decoding should not really use much cpu.
>
> I'm not even sure we can control that. Some games seem to set up their
> own mixing threads and such (looking at the SDL Win32 code it calls
> SetThreadPriority itself).
>
> Also this issue is wider than just audio, though this is where it hurts
> us the most. I guess there are other cases where a Windows program needs
> to raise thread priorities. Isn't Photoshop susceptible to scheduling
> differences?
>
> > Lastly, and this is not a comment about wine but all programming in
> > general, multithreading cannot be left up to chance.
>
> What do you suggest, that we find some way to make audio threads in Wine
> block/swap with more intensive threads? I'm having a hard time imagining
> how this would work ... we don't control what the other threads are
> doing, so ... hmmmm. I don't see any way to guarantee that every other
> thread will block on the audio thread often enough that the buffers
> never run down.
I know I didn't offer a solution, just standard rules for multithreaded
application writing. The fact that wine is a compatibility layer rather than
its own application is most of your problem. Is there no way wine could have
an audio thread that does nothing but the compatibility component between the
running win32 application and the alsa drivers? That would use very little
cpu even if the win32 app internally does funky decoding and whatever else.
Cheers,
Con
More information about the wine-devel
mailing list