Jeremy White wrote:
Hi all,
This is simply a renaming and reorganizing post; Dimi wacked me with a clue bat, and I am now looping Ingo Molnar into this conversation (and I am doing it at great haste since he made noises about helping <grin>).
The thread started here: http://www.winehq.org/hypermail/wine-devel/2004/08/0306.html http://www.winehq.org/hypermail/wine-devel/2004/09/0081.html
picked up a bit here: http://www.winehq.org/hypermail/wine-devel/2005/01/0331.html
(the multiple URLs are entirely due to the apparent failing of hypermail to span month boundaries).
I've asserted that a large obstacle we face is our inability to replicate the Windows concept of thread priorities.
Ove recently added what struck me as a very interesting suggestion:
The biggest problem is that there is no way to say to the kernel that one thread is more important than another without permanently renicing all other threads. A potential kernel solution to the problem would be to implement process scoping in the kernel, i.e.
pthread_attr_setscope(attr, PTHREAD_SCOPE_PROCESS)
and then allow threads scoped this way to be set to high priority, since with a process scope, these threads should only preempt other threads in the same process (i.e. Wine), not threads run by other Linux apps, and thus the security concerns of elevated priority threads are irrelevant.
Allowing a process-scoped thread to set the scheduling policy to SCHED_RR in order to inhibit the kernel's interactivity priority boost system would also help.
And that brings us up to date.
I posted a patch for SCHED_BOUND to do just such a thing to the linux kernel mailing list 2 months ago. Noone responded so I didn't pursue it.
Con