Implement THREAD_PRIORITY_TIME_CRITICAL

[Andreas Mohr]

Hi,

On Mon, Apr 03, 2006 at 04:04:05PM +0100, Aneurin Price wrote:
> Anyway, surely the `best' way would be for the kernel to support 
> user-level `real-time' priorities like the ck kernels. Anybody know why 
> they don't like the idea of that kind of thing?

Con Kolivas is doing some very active development and he's feeding a lot
back to mainline, however that does take some time, and of course you don't
add non-root realtime support too lightly to mainline without LOTS of
previous testing.

> More on topic, does this simply change Wine's priority or does it act on 
> a per-thread level? Most of the issues I've seen have been caused by the 
> audio thread being starved by the others, and is often semi-solved by 
> running Wine at nice 19, which seems counter-intuitive but appears to 
> get around some sheduling problems (priority inversions spring to mind). 
> This has the side effect of course that you have to make sure no other 
> process is going to steal the cpu time from under you. Am I talking 
> about the same issue as everyone else or have I got the wrong end of the 
> stick?

It is a per-thread setting (both in the Win32 API and in SCHED_ISO),
and as such is *much* less ugly than going the shotgun approach by doing
grave priority changes on Wine as a whole.

BTW, I have to admit that I'm astonished that someone before stated that
SCHED_ISO wasn't sufficient for his audio work. In this case it might have
been for two reasons that I can think of:
a) the thread doing the audio work taking *waaay* too much CPU for its
   SCHED_ISO setting (SCHED_ISO has a CPU time limit, and that's a Good Thing)
b) this thread or another thread calling some bloaty kernel function on a
   non-preemptible kernel, thus hindering timely rescheduling

I'd declare both cases to be Buggy (tm) and in need of fixing.
SCHED_ISO shouldn't be the problem here, methinks.

Or, to put it another way: I'd say that if SCHED_ISO isn't enough resources
that there's either a general system overload issue (machine too slow) or
a matter of the work to be done being too much (root-only realtime scheduling
would pose a harder load on the system that would then probably be too much
to handle for the *user* anyway).

Andreas

-- 
Please consider not buying any HDTV hardware! (extremely anti-consumer)
Bitte kaufen Sie besser keinerlei HDTV-Geräte! (extrem verbraucherfeindlich)
Infos:
http://www.hdboycott.com   http://www.eff.org/IP/DRM/   http://bluraysucks.com