Jeremy White wrote:
Specifically, there are other areas of interest when you think about timing and scheduling. First is the Windows very clear cut 'foreground window' boost. I have no idea how this maps into the Linux interactivity strategy. They seem to be roughly equivalent, and I never found an application that relied on that timing.
We do nothing of the sort. There is no special casing in the kernel for any processes that aren't kernel threads. However, the more frequently a task sleeps, the more priority it is rewarded with. That tends to select out interactive tasks.
That connects to the theoretical flaw in Wine (the whole use of the Wine server) that should make us vulnerable to all sorts of unexpected context switches, creating timing patterns unfamiliar to Windows applications, and causing problems. And yet, from observation, I never see any such unexpected context switches. The Linux kernel priority boost for pipes seems to protect us here; we should make sure we understand why and let the kernel guys know that we depend on it, so they don't knock it out from under us some day.
No chance again. The reason you get priority boost on pipes is a task is waiting, therefore it is sleeping.
Fourth, based on your reply to my earlier email, I suspect I do not understand how time quanta are assigned. In fact, I had come to some conclusions at one point last fall, that I can no longer convince myself of (I was persuaded that a thread that constantly yielded had it's time quanta dranstically reduced; I can no longer reproduce that). Further, time quanta differences can be crippling to Wine. Photoshop, for example, relies on reliable 5ms timing, and if it doesn't get it, it doesn't work. Similarly, I could swear I had a problem
That can't be true. What you are saying is it needs at least 5ms timeslice on hardware that is equal to or faster than the machine you tested it on. We cannot guarantee any timeslice of any size will occur uninterrupted in the linux kernel. For tasks that are not nice'd, the usual minimum slice is 10ms. But if something higher priority than it wakes up in the interim, it will be preempted even if it is 50 microseconds into its timeslice.
case in IE where two threads were interdependent, and the one thread never got a large enough quanta to keep the second thread happy (and this then caused a spiral that led to the small quanta for thread A).
This is not at all unusual. If there is no locking between threads, and you simply hope that one will complete in time for the other, you will get various degrees of priority inversion. Native linux applications do it too, and 2.6 has forced them to improve their coding principles (see the thread on 'blender' in the linux kernel mailing list during 2.5 development. There are various algorithms that have been tried to detect when this is happening and inherit appropriate priorities, but they have their own overhead and aren't as effective as proper blocking in the first place.
Sadly, I didn't take good notes, so I have to go back and relearn that case again. And, knowing me, I probably completely misunderstood it anyways :-/.
Not really. It sounds very much like you've got the thrust of the problem to me :)
Sorry to ramble on; it's just tough around here, because everyone is tired of hearing me claim that every bug is a timing problem... <grin>
Exactly.
Generous use of blocking where appropriate is the answer to being friendly to any scheduler. Hoping dependant threads will complete in time is futile as the speed of execution of each thread will change on different schedulers, hardware etc.
Cheers, Con