http://bugs.winehq.org/show_bug.cgi?id=2578
Summary: file write performance over NFS very poor due to dup+write+close Product: Wine Version: unspecified Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: greg@electricrain.com
I run wine on a diskless workstation to run some windows video transmogrifying applications. Needless to say, video files are huge so this app does a lot of IO. Under wine, the effective write speed of the application is reduced to a few hundred kbytes/sec on nfs filesystems. Performance is probably reduced on local disks as well (i don't have wine on a system with a disk to test that) as the close() presumably waits for the data to be committed to disk.
Doing an strace of the wine process that does the disk IO shows:
rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [RTMIN], 8) = 0 write(16, "&\0\0\0\0\0\0\0\0\0\0\0d\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(15, "\0\0\0\0\0\0\0\0\24\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(20) = 23 write(23, "\0\0\1\272D\37T\222LU\1\211\303\370\0\0\1\300\7\354\201"..., 2048) = 2048 close(23) = 0 ... repeated for a long long time ...
A check in /proc/PID/fd/ shows that 20 is indeed the output file (15 and 16 are the pipes between the wine processes). Not seen here is the input file (17) which is read much more efficiently in 3 128k chunks every so often (though it is read in an unnecessary dup+read+close sequence which causes extra NFS getattr latency)
tcpdump on the nfs client shows that three round trip latencies are involved in every 4096 bytes that wine writes:
getattr + response, write + response, commit + response.
with a normal linux program that doesn't close its fd (forcing the commit and the getattr before the next write) writing goes at full speed.
I have observed this behaviour with every version of wine i've used in the past year. Currently i'm using 20041019. It occurs regardless of if the client is running a linux 2.4 or 2.6 kernel. The kernel is doing the correct thing. Close forces a commit to ensure that the data is on stable storage before returning (close will return an error otherwise; wine doesn't appear to check for an error on close).
Proposed fix: stop the dup+close nonsense. Grepping thru the wine code I'm guessing that it is in dlls/ntdll/server.c where this all occurs with the wine_server_handle_to_fd() and wine_server_release_fd() functions that implement a dup() and a close() respectively.