Does WINE have any problem with either Hyperthreading or SMP? I've found that locking the Tribes Vengeance dedicated server to a single logical CPU seems to give me better performance as the server fills with players. CPU usage seems significantly lower (45% versus 65%). Is this likely to be a WINE issue or a TV issue? (TV is based on the Unreal Tournament engine, with the Havok physics engine integrated to handle vehicle. Alas, unlike UT2004, there's no native Linux server for TV.)
More here:
http://lists.matureasskickers.net/pipermail/tvservers/2004-December/000186.html
I want to try disabling HT or setting affinity on my co-admin's Win2003 server to see if he sees the same boost.
On wtorek 21 grudzień 2004 12:46 pm, Kenneth Porter wrote:
Does WINE have any problem with either Hyperthreading or SMP? I've found that locking the Tribes Vengeance dedicated server to a single logical CPU seems to give me better performance as the server fills with players. CPU usage seems significantly lower (45% versus 65%). Is this likely to be a WINE issue or a TV issue? (TV is based on the Unreal Tournament engine, with the Havok physics engine integrated to handle vehicle. Alas, unlike UT2004, there's no native Linux server for TV.)
What kernel version were you running under? Could that be related at all to thread CPU affinity under 2.6?
Cheers, Kuba Ober
--On Tuesday, December 21, 2004 4:57 PM -0500 Kuba Ober kuba@mareimbrium.org wrote:
What kernel version were you running under? Could that be related at all to thread CPU affinity under 2.6?
2.6.8-1.521smp on Fedora Core 2. What's the issue you're referring to?
On wtorek 21 grudzień 2004 05:36 pm, Kenneth Porter wrote:
--On Tuesday, December 21, 2004 4:57 PM -0500 Kuba Ober
kuba@mareimbrium.org wrote:
What kernel version were you running under? Could that be related at all to thread CPU affinity under 2.6?
2.6.8-1.521smp on Fedora Core 2. What's the issue you're referring to?
Well, IIRC most 2.6 kernels use the O(1) scheduler by default, and that scheduler has strong CPU affinity. But since in your case locking the process helps, this isn't a problem.
I suspect that something else is going on that probably has little to do with wine but a lot to do with that application's memory access patterns. Hyperthreading has known cases in which if memory is the contention source, running two threads on same physical CPU but separate logical ones will slow things down.
Since wine is a multi-process thingo, probably the application process and wineserver have been thrasing that single CPU's caches by trying to run concurrently on two logical CPUs. If you have SMP HT machine, it'd be safest methinks to run the app locked to one logical CPU on given physical CPU, and the wineserver on either the same logical CPU or on a different physical CPU.
I hope I make sense :)
Cheers, Kuba Ober
--On Monday, January 03, 2005 1:15 PM -0500 Kuba Ober kuba@mareimbrium.org wrote:
I suspect that something else is going on that probably has little to do with wine but a lot to do with that application's memory access patterns. Hyperthreading has known cases in which if memory is the contention source, running two threads on same physical CPU but separate logical ones will slow things down.
Thanks, I'll have to see if I can find out more about that so I can pass it upstream to the app's devs.
Since wine is a multi-process thingo, probably the application process and wineserver have been thrasing that single CPU's caches by trying to run concurrently on two logical CPUs. If you have SMP HT machine, it'd be safest methinks to run the app locked to one logical CPU on given physical CPU, and the wineserver on either the same logical CPU or on a different physical CPU.
I hope I make sense :)
Yep, given your first paragraph. Thanks for the details.
-
Kenneth Porter -
Kuba Ober