Speeding up wineserver syncronization objects with shared memory

[Alexandre Julliard]

David Howells <dhowells at cambridge.redhat.com> writes:

> My main gripe is the slow speed of access to files... Every Read/WriteFile
> goes to the wineserver to convert the handle into a file descriptor and to
> check for locking. The FD is then passed back over a UNIX domain socket, used
> once and then closed.

Note that we are no longer doing that in the latest versions; the file
descriptor is only transferred once, and all further requests are done
on a pipe which is faster than a socket.

> Gavriel State <gav at transgaming.com> wrote:
> > In my experience Alexandre far prefers incremental change to kind of
> > approach you're taking.  Using that kind of approach will improve the
> > chances that your code will make it into Wine at some point.
> 
> Hmmm... It's difficult to determine how to do it incrementally without making
> for even more work, but I think I know what you mean.

The kernel module itself may be hard to do incrementally, but you
should really consider reusing the existing server API so that your
module can be plugged in easily. For instance your module entry points
should be the same as the server requests, and use the same request
structures.

> Context switching is the main element of it. Going to the wineserver and back
> again just for a ReadFile() call or a Wait*() function incurs a fairly serious
> penalty (particularly on an X86, I think). Plus there's no requirement for the
> kernel to pass the remains of your timeslice to the wineserver and back
> again.

I still think that it should be possible to improve that by a small
kernel hack. It will never be as fast as doing everything in the
kernel of course, but it may just be fast enough to avoid the need to
reimplement the whole server.

> Look at the VM size of something like MS Word, and think of not having to
> allocate buffers to store all those DLLs, thus eating a massive chunk out of
> your machines total VM.

Have you measured how many dirty pages you can avoid with your change?
It seems to me that in most cases, when the dll is loaded at its
preferred address, the number of pages made dirty by the fixups should
be quite small anyway.

-- 
Alexandre Julliard
julliard at winehq.com