tir, 08.07.2003 kl. 04.27 skrev Troy Rollo:
I've been looking at the various efforts over the years to speed up wineserver or eliminate it altogether (by substituting a kernel service). Certainly the current degree of reliance on a separate process that is scheduled according to the operating system's own priorities creates significant speed problems. Some of this migh be alleviated by boosting the priority of the wineserver process or by making it a real time task, but there are still some operations it appears to be performing some operations that result in a yield and hence subject it to another wait in the queue for at least one time slice.
Which operations are you really concerned about? Just synchronization (WaitFor*, SetEvent, etc), file requests (get_unix_fd), or "all of them" in general?
Even if the wineserver itself could be sped up in this way, individual processes would stull be subjected to time waiting in the queue after they make a request of wineserver. The problem becomes more severe on a heavily loaded system.
Yeah, tell me about it. It seems that when trying to run some of the latest 3D games under WineX, about half of the cpu time is spent on wineserver communication, on average.
The approaches suggested so far:
Shared memory
Suffers from reliability problems which may allow one process to put the system in an inconsistent state.Kernel module
The only effort so far seemed to put way too much into the kernel, and was abandoned over two years ago.
And then there's the approach that Alexandre suggested when he saw that big kernel module. Currently I have a design in mind that would implement something along those lines, but since Gav seems in love with the shared-memory approach, I don't know if I'd get that much time to work on it.
Basically this module I'd like to write would not change too much in the existing wineserver. But instead of unix sockets (AF_UNIX), we'd make the wineserver use a "wine socket" type (AF_WINE) implemented in the module, which would work a bit like unix sockets, but which would intercept wineserver requests from wine clients and process the most time-critical types straight in the kernel. It'd pass any request it doesn't implement on to the regular wineserver. The regular wineserver could do ioctls for stuff like "signal this object" to tell the module when it should satisfy wait requests handled by the module and such. And each wineserver listening socket would be its own namespace.
While it's probably going to be hard to get all the details and races right, this would accelerate many server requests while also avoiding any kind of user-space shared memory, which has always been the main concern. And it wouldn't be trying to do too much.