Jeremy White wrote:
You might try putting traces around the conditional YieldExecution on line 730 of ntdll/sync.c and see if that chews up time; if it does, removing the Yield might help.
Removing the Yield fixes a regression in Need For Speed III where the loader and server consume 100% of the CPU. This is with RH 9 which is a 2.4 kernel.
Removing the Yield fixes a regression in Need For Speed III where the loader and server consume 100% of the CPU. This is with RH 9 which is a 2.4 kernel.
When did that regression first start? The mmtime and ntdll/sync.c code has been this way since late last fall.
The Yield is, imho, correct, except that it exposes the fact that we don't correctly implement Windows priority schemes. That can create nasty conditions.
But I wonder if something else changed that is causing this.
I'm particularly surprised to find it on a 2.4 kernel; the 2.4 kernel quanta was ~ 40 ms, which made Linux a bit less sensitive to cpu hogging threads.
Cheers,
Jeremy
Jeremy White wrote:
Removing the Yield fixes a regression in Need For Speed III where the loader and server consume 100% of the CPU. This is with RH 9 which is a 2.4 kernel.
When did that regression first start? The mmtime and ntdll/sync.c code has been this way since late last fall.
About that time. I believe itunes and some other programs were seeing 100% cpu usage at that time. Apparently they got fixed but I was disappointed when the NFS3 problem didn't go away.
About that time. I believe itunes and some other programs were seeing 100% cpu usage at that time. Apparently they got fixed but I was disappointed when the NFS3 problem didn't go away.
Could you try the attached experimental patch and see if it eliminates the NFS3 problem?
Cheers,
Jer
Jeremy White wrote:
Could you try the attached experimental patch and see if it eliminates the NFS3 problem?
It fixes the problem in NFS3 when using hardware accelerated sound. Sound is really messed up when using HardwareAcceleration = Emulation.
The direct sound regression tests run better in emulation mode but still not as good as the used to.
Robert Reif wrote:
Jeremy White wrote:
Could you try the attached experimental patch and see if it eliminates the NFS3 problem?
It fixes the problem in NFS3 when using hardware accelerated sound. Sound is really messed up when using HardwareAcceleration = Emulation.
The direct sound regression tests run better in emulation mode but still not as good as the used to.
Could you recap this for me? Afaik, we have 4 cases: 1) Current CVS tip 2) With a hack to kill the yield in wait timeouts 3) With my experimental priority adjustor 4) Behavior last fall before I started messing around.
So, #4 worked well with NFS3, in both modes? #3 works fine with NFS3, but only in hardware accel sound. #2 works with NFS3; with both sound modes? #1 doesn't work at all, is that right? Or does it work with hardware accel sound?
Cheers,
Jer
Jeremy White wrote:
Could you recap this for me? Afaik, we have 4 cases:
- Current CVS tip
- With a hack to kill the yield in wait timeouts
- With my experimental priority adjustor
- Behavior last fall before I started messing around.
So, #4 worked well with NFS3, in both modes?
correct
#3 works fine with NFS3, but only in hardware accel sound.
correct
#2 works with NFS3; with both sound modes?
correct
#1 doesn't work at all, is that right? Or does it work with hardware accel sound?
Sound is OK when doing hardware acceleration but the game is unplayable because it's running way slower than real time because the loader and server are using 90+% of the CPU.
#1 doesn't work at all, is that right? Or does it work with hardware accel sound?
Sound is OK when doing hardware acceleration but the game is unplayable because it's running way slower than real time because the loader and server are using 90+% of the CPU.
Hmm. This is very interesting; I may have to find myself a copy of NFS3 and Myst; these may be useful test cases for counter examples of scheduling problems. What I really need are examples to set opposite each other (e.g. Powerpoint vs Myst).
Sadly, I'm out pretty much all week, so I'll have to pick this up later.
Cheers,
Jer
Jeremy White wrote:
When did that regression first start? The mmtime and ntdll/sync.c code has been this way since late last fall.
I'll just mention that, assuming you are referring to this patch: http://cvs.winehq.org/patch.py?id=14198 it also causes a regression in Myst. Though I am not convinced the fault is in the patch, rather than the patch exposing some other problem.
The Yield is, imho, correct, except that it exposes the fact that we don't correctly implement Windows priority schemes. That can create nasty conditions.
But I wonder if something else changed that is causing this.
I'm particularly surprised to find it on a 2.4 kernel; the 2.4 kernel quanta was ~ 40 ms, which made Linux a bit less sensitive to cpu hogging threads.
Unfortunately, Myst appears to only work under Wine with rather old kernels. It works fine for me on RH7.3, kernel 2.4.18, as long as I back out that mmtime patch. But Myst fails to work on RH9, kernel 2.4.20, for reasons unrelated to the mmtime patch. However, it fails after the point where the above patch causes the regression (in the intro Quicktime sequence). So even on later kernels, Myst might be a good testbench, though I have not tried a later kernel. Surely everyone has an old copy of Myst around somewhere ;)
It was discussed a bit more here: http://www.winehq.org/hypermail/wine-users/2005/01/0260.html
I'll just mention that, assuming you are referring to this patch: http://cvs.winehq.org/patch.py?id=14198 it also causes a regression in Myst. Though I am not convinced the fault is in the patch, rather than the patch exposing some other problem.
Would you mind trying my experimental patch to see if it makes a difference? If it doesn't, could you also try the attached patch and see if that does?
Cheers,
Jeremy
Jeremy White wrote:
I'll just mention that, assuming you are referring to this patch: http://cvs.winehq.org/patch.py?id=14198 it also causes a regression in Myst. Though I am not convinced the fault is in the patch, rather than the patch exposing some other problem.
Would you mind trying my experimental patch to see if it makes a difference? If it doesn't, could you also try the attached patch and see if that does?
The experimental patch did not help. This small yield patch seemed to help a little, but did not fix the problem. Without backing out the winmm patch, the sound and motion are both jerky, and eventually the intro Quicktime clip freezes up completely. It seemed to take longer to freeze up with the patch below than with the experimental patch.
After backing out the winmm patch, sound and motion are both smooth (though sound is not perfect, but that is a different issue). Tested with a 20041201 Wine version on RH7.3. There seem to be other problems now with a current CVS version on RH9, so I could not test there.
By the way, I will be away from my computer all this week. So any further testing will need to wait until next week sometime.
Cheers,
Jeremy
Index: dlls/ntdll/sync.c
RCS file: /home/wine/wine/dlls/ntdll/sync.c,v retrieving revision 1.42 diff -u -r1.42 sync.c --- dlls/ntdll/sync.c 14 Jan 2005 19:54:39 -0000 1.42 +++ dlls/ntdll/sync.c 12 Feb 2005 22:34:04 -0000 @@ -727,7 +727,9 @@ /* A test on Windows 2000 shows that Windows always yields during a wait, but a wait that is hit by an event gets a priority boost as well. This seems to model that behavior the closest. */ +#if 0 if (ret == WAIT_TIMEOUT) NtYieldExecution(); +#endif
return ret;}
Unfortunately, Myst appears to only work under Wine with rather old kernels. It works fine for me on RH7.3, kernel 2.4.18, as long as I back out that mmtime patch. But Myst fails to work on RH9, kernel 2.4.20, for reasons unrelated to the mmtime patch. However, it fails after the point where the above patch causes the regression (in the intro Quicktime sequence). So even on later kernels, Myst might be a good testbench, though I have not tried a later kernel. Surely everyone has an old copy of Myst around somewhere ;)
It was discussed a bit more here:
Myst 4 chokes during the intro sequence because of dsound (and probably mmtime somewhere down the line). using the winealsa driver (which seems to not work) makes it work again.
I've got a copy of Myst on the shelf, so I'll see if it has similar problems. (both being ubisoft etc..)
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
-
Duane Clark -
Jeremy White -
Oliver Stieber -
Robert Reif