Jeremy White wrote:
Fyi,
I spent a great deal of time this past fall exploring Wine scheduling issues, and I thought I would post what I learned.
The most critical point is Wine was pretty badly broken; it simply had a number of flaws in how scheduling was done.
First, the winmm timer, used by a lot of programs, was pretty awful. That has now been fixed, and I believe that it now works correctly.
Second, we did not synchronize Wine message times with X11 message times properly. Fixing that resolved some issues with Photoshop (and given that Ove reworked that patch into WineX the same day I submitted it, I'd guess it fixed some games too <grin>).
Third, Wine did not yield the processor properly at points where Windows does, including Sleep(0) and certain event conditions. That's now been (mostly) fixed, I think.
Fourth, the Wine server had an issue with the way it managed it request queues. To be honest, I don't understand this bug or the fix; all I know is that Mike McCormack figured this one out and posted a magic fix. This was, I believe, the primary reason that the wineserver would chew 100% cpu with iTunes.
Beyond that, there are a number of ways that Wine 'gets lucky' and Just Works (TM) works on the Linux scheduler, in ways that we couldn't have asked for.
First, because many Wine calls resolve into a wineserver call, and a wineserver call involves a write to a pipe, we potentially risk yielding the processor far more often in Wine that a Windows program would 'naturally' do so on Windows; opening us to horrendous timing bugs. However, in practice, because the Wine server often handles requests within a single quanta, and because waiting on a pipe with data gets a priority boost in Linux, the net effect is what Wine wants. (Thread A makes a request, yields to the Wine server who gets in ahead of all other threads, does the requests, sends the response back, and Thread A regains control before any other Wine thread because it got a priority boost).
An excellent investigation and summary, thanks! The situation was worse than I anticipated. Thankfully it looks like you're not track.
Second, the new 2.6 average time quanta of 100 ms is comparable to the observed Windows quanta of 115 ms (I may have that wrong, but I recall they were quite close), although the old, much smaller time quanta masked a number of Wine scheduling problems. But, in theory, having this longer time quanta should let us better replicate Windows scheduling behavior.
Actually this wont help you. The more frequent round robinning of tasks with shorter timeslices blurs any priority differences. With longer timeslices all you'll get is "resonance"
However, we still have some issues. First, the problem with thread priorities still remains an issue. A non zero number of important applications rely on Windows priorities to change timing behavior to make their applications run properly. ([editors note: imho, these are poorly written apps, but we have to support them as they are; wishing that MS would rewrite PowerPoint to my spec is amongst the most futile things I can imagine]).
There is a patch Mike worked up which makes a theoretical improvement to the Wine server (pull requests from its queue in thread priority order), but we have no evidence that change makes any difference, and Mike backed away from it when he found the afore mentioned 'correct' fix. Nonetheless, I think it is conceptually 'right', so we probably should bug Mike into redoing that patch.
I've played with a number of artificial ways to try to replicate this within Wine, and have come up with a few compromises, but nothing works perfectly (or, more importantly, worked up nothing that Alexandre would apply <grin>). If you do try to exactly mirror Windows priorities, for example (running as root, say), you run into issues where the wineserver gets starved and Wine stops functioning.
Candidly, that's where I'm stuck. I'm going to revisit a few of my 'problem' apps hopefully sometime this year and see if I can cobble together a hack that works best. Ove, I haven't tried the signalling approach; that seems like an interesting idea.
Sadly, short of asking the Linux guys to rewrite the Linux kernel scheduler to exactly mimic Windows behavior, I'm not really sure if there is a lot we can do to get this exactly right.
Well the scheduler is not going to be rewritten any time soon (trust me, I've tried :P). Tell me what remaining requirements your threads have that you are unable to achieve at the moment and I'll see if I can help with my understanding of the priority system as it is, in a generic way that hopefully will work across scheduler designs.
Cheers, Con