Speeding up wineserver (again)

Ove Kaaven ovek at arcticnet.no
Mon Jul 7 22:38:00 CDT 2003


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.





More information about the wine-devel mailing list