[Bug 59440] New: NTSync doesn't work very well in ONGEKI Re:Fresh.
http://bugs.winehq.org/show_bug.cgi?id=59440 Bug ID: 59440 Summary: NTSync doesn't work very well in ONGEKI Re:Fresh. Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: admin@uright.icu CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: --- Created attachment 80422 --> http://bugs.winehq.org/attachment.cgi?id=80422 Kernel: 6.19.2-1-MANJARO I looked at perf.data, and 40% of the time was spent on the function NtWaitForSingleObject, which is obviously abnormal. I checked the locks, and one unnamed lock had an average wait time of 2.33 seconds. Since I can't upload more than two attachments, the lock report for that line is as follows: Name acquired contended avg wait total wait max wait min wait 600487 600487 3.88 us 2.33 s 91.82 us 568 ns 67 67 193.90 us 12.99 ms 480.07 us 2.38 us rcu_state 17 17 2.36 us 40.13 us 2.93 us 1.67 us 13 13 3.13 us 40.67 us 4.61 us 1.80 us rcu_state 3 3 2.52 us 7.57 us 3.02 us 2.24 us 2 2 1.58 us 3.16 us 1.80 us 1.36 us jiffies_lock 2 2 2.24 us 4.47 us 2.33 us 2.15 us 1 1 1.90 us 1.90 us 1.90 us 1.90 us 1 1 1.47 us 1.47 us 1.47 us 1.47 us 1 1 3.23 us 3.23 us 3.23 us 3.23 us 1 1 7.11 us 7.11 us 7.11 us 7.11 us 1 1 7.52 us 7.52 us 7.52 us 7.52 us Each lock was contended once, which seems to be caused by some sort of conflict. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59440 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Product|Wine-staging |Wine --- Comment #1 from Zeb Figura <z.figura12@gmail.com> --- (In reply to admin from comment #0)
I looked at perf.data, and 40% of the time was spent on the function NtWaitForSingleObject, which is obviously abnormal.
It might be and it might not be. perf can be very misleading especially when you're dealing with a situation where symbols are missing. What's the actual performance characteristics of the game? How does it perform with server-side synchronization, with ntsync, and (if you tested) with esync or fsync?
I checked the locks, and one unnamed lock had an average wait time of 2.33 seconds.
Looks like you're misreading—the *total* wait time is 2.33 seconds (since the lock is taken many many times), the average wait time is only 3.88 µs.
Since I can't upload more than two attachments, the lock report for that line is as follows:
You can upload extra attachments in a following comment. Or archive them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59440 --- Comment #2 from admin@uright.icu --- (In reply to Zeb Figura from comment #1)
(In reply to admin from comment #0)
I looked at perf.data, and 40% of the time was spent on the function NtWaitForSingleObject, which is obviously abnormal.
It might be and it might not be. perf can be very misleading especially when you're dealing with a situation where symbols are missing.
What's the actual performance characteristics of the game? How does it perform with server-side synchronization, with ntsync, and (if you tested) with esync or fsync?
I checked the locks, and one unnamed lock had an average wait time of 2.33 seconds.
Looks like you're misreading—the *total* wait time is 2.33 seconds (since the lock is taken many many times), the average wait time is only 3.88 µs.
Since I can't upload more than two attachments, the lock report for that line is as follows:
You can upload extra attachments in a following comment. Or archive them.
I've traced one of the hotspots to SleepEx(0, TRUE), which accounts for nearly half the CPU time. On Windows it returns quickly, but under Wine it just calls server_wait, which ends up going through wineserver and involves at least four syscalls. My proposed fix is to add a fast path in NtDelayExecution that uses linux_wait_objs. I'll send out a patch shortly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59440 --- Comment #3 from admin@uright.icu --- Created attachment 82256 --> http://bugs.winehq.org/attachment.cgi?id=82256 alertable-delay-fast-path -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59440 --- Comment #4 from admin@uright.icu --- Comment on attachment 82256 --> http://bugs.winehq.org/attachment.cgi?id=82256 alertable-delay-fast-path An AI POC -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59440 --- Comment #5 from admin@uright.icu --- Comment on attachment 82256 --> http://bugs.winehq.org/attachment.cgi?id=82256 alertable-delay-fast-path diff --git a/dlls/ntdll/unix/sync.c b/dlls/ntdll/unix/sync.c index 829c712..daf6d26 100644 --- a/dlls/ntdll/unix/sync.c +++ b/dlls/ntdll/unix/sync.c @@ -445,7 +445,12 @@ static NTSTATUS linux_wait_objs( int device, DWORD count, const int *objs, WAIT_ return type != WaitAll ? args.index : 0; } if (errno == EOWNERDEAD) return STATUS_ABANDONED + (type != WaitAll ? args.index : 0); - if (errno == ETIMEDOUT) return STATUS_TIMEOUT; + if (errno == ETIMEDOUT) + { + /* match server_wait(), which always yields on a timed out wait */ + NtYieldExecution(); + return STATUS_TIMEOUT; + } return errno_to_status( errno ); } @@ -904,6 +909,7 @@ static NTSTATUS inproc_wait( DWORD count, const HANDLE *handles, WAIT_TYPE type, NTSTATUS ret; if (inproc_device_fd < 0) return STATUS_NOT_IMPLEMENTED; + if (alertable && (alert_fd = get_inproc_alert_fd()) < 0) return STATUS_NOT_IMPLEMENTED; assert( count <= ARRAY_SIZE(syncs) ); objs[0] = -1; /* make gcc happy, otherwise it thinks objs is not initialized */ @@ -917,7 +923,6 @@ static NTSTATUS inproc_wait( DWORD count, const HANDLE *handles, WAIT_TYPE type, objs[i] = syncs[i]->fd; } - if (alertable) alert_fd = get_inproc_alert_fd(); ret = linux_wait_objs( inproc_device_fd, count, objs, type, alert_fd, timeout ); while (count--) release_inproc_sync( syncs[count] ); @@ -2423,9 +2428,16 @@ NTSTATUS WINAPI NtDelayExecution( BOOLEAN alertable, const LARGE_INTEGER *timeou { unsigned int status = STATUS_SUCCESS; - /* if alertable, we need to query the server */ + /* if alertable, try the in-proc fast path first, otherwise we need to + query the server */ if (alertable) { + if ((status = inproc_wait( 0, NULL, WaitAny, TRUE, timeout )) != STATUS_NOT_IMPLEMENTED) + { + if (status == STATUS_TIMEOUT) status = STATUS_SUCCESS; + return status; + } + /* Since server_wait will result in an unconditional implicit yield, we never return STATUS_NO_YIELD_PERFORMED */ if ((status = server_wait( NULL, 0, SELECT_INTERRUPTIBLE | SELECT_ALERTABLE, timeout )) == STATUS_TIMEOUT) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla