March 2001 - Wine-Devel - list.winehq.org

Port to Sparc64

by Jutta Wrage

Hi! What about the suggested port to Sparc? Did anybody work on that again? There was a question in the Wine-HOWTO mailing list. cu Jutta -- http://www.witch.westfalen.de/ Wine-HOWTO http://www.la-sorciere.de/wine/

March 7, 2001

Re: Speeding up wineserver syncronization objects with shared memory

by David Howells

> Note that we are no longer doing that in the latest versions; the file > descriptor is only transferred once, Fair enough... I see that ZwClose/NtClose isn't actually a problem (since unlike most other Zw* calls, it can't affect other processes). Oh... I see how you're doing it... sending the handle->fd translate request to the server, which sends a response saying you've got it cached; then using dup() locally to emulate the old behaviour; and then closing the fd. So this saves you the cost of the fd transfer net packet. Though you still have to do the two context switches, which is my main contention. > and all further requests are done on a pipe which is faster than a socket. True, but I'd have thought that the context switches involved are still a cost you can't get rid of so easily. Out of interest, how do you plan on doing the locking stuff for Read/WriteFile? Cache it locally? It is unfortunate, but you can't really make use of UNIX file locking, since this is mostly advisory and as such doesn't actively stop read/write calls. > 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. What? Miss the opportunity to implement "int 0x2e" directly? *grin* Seriously, though, whilst this'd be a lot easier in many ways (and it would allow you to avoid the context-switch penalties), you wouldn't be able to take full advantage of the available support in the kernel, which is more capable than the standard UNIX userspace API suggests. It'd still have to paste handles to fds for most file operation calls, and you'd still have the PE Images soaking up a fair amount of memory. If this is what you want, then it might be better done as a network protocol module that just pretends to be a wineserver, and supports the same read/write/sendmsg/recvmsg interface. (It'd have to be a network protocol to be able to get sendmsg/recvmsg calls): int serv = socket(AF_WINE,SOCK_STREAM,0); short addr = AF_WINE; connect(serv,(struct sockaddr*)&addr,sizeof(addr)); > 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. If you want to suggest exactly what you'd like to see as a hack... > 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. As far as I've observed (I've got Win2000 available), most Windows DLL's have 512-byte (sector) alignment internally, _not_ 4096-byte (page) alignment for the sections. This means that the separate sections can't be mmap'd (or else they'd lose their required relative relationships): VIRTUAL_mmap() { ... /* mmap() failed; if this is because the file offset is not */ /* page-aligned (EINVAL), or because the underlying filesystem */ /* does not support mmap() (ENOEXEC,ENODEV), we do it by hand. */ ... } This appears to happen a lot. And then _all_ the pages in that section are dirty, irrespective of whether fixups are done or not. Also, since DLLs and EXEs are not compiled as PIC (the MSDEV compiler not having such an option as far as I can recall), the fixup tables usually seem to apply to just about every page in the code section. I'll have to write a small program to collect some statistics:-) As for the DLL being loaded at it's preferred address, the kernel module jumps around the fixup stuff, and doesn't even consider trying to perform it. Plus pages that have been altered by the fixup code are actually marked _clean_ by the VM subsystem, and can thus be simply discarded when physical memory needs to be reclaimed. David

March 7, 2001

Re: Wineserver semantics

by Alexandre Julliard

Ryan Cumming <bodnar42(a)bodnar42.dhs.org> writes: > What about having the file descriptor cache explictly invaildated? Like, > the server keeps track of which file descriptors the various wine > processes have cached, and if a process closes or performs some locking > operation on a file descriptor, all the other wine proceses that are using > that file descriptor are explictly notified. This way processes can assume > a file descriptor is valid unless told otherwise... would this be any > better performance-wise? Does it fit in to the wineserver architecture > nicely? ;) Not really; you'd either need to callback into the client, which creates a lot of synchronisation issues, or use a shared memory area which implies locking. Either way doesn't really fit in the current model. And as mentioned already we'll probably still need a server call on each file access to implement file locking. -- Alexandre Julliard julliard(a)winehq.com

March 7, 2001

Re: Wineserver semantics

by Ryan Cumming

On 6 Mar 2001, Alexandre Julliard wrote: > I'm not sure what you mean by 'exclusive access to the file'. If you > mean file locking then this is not implemented, so there cannot be any > race ;-) Currently the client is allowed to cache the descriptor, but > before each read/write it checks with the server that the cache is > still valid. There is a race that the handle can be modified between > the check and the actual read, this will cause either a bad handle > error or a read from the wrong file; but this is no different from > what happens under Windows if the client is manipulating handles > concurrently with a ReadFile. > What about having the file descriptor cache explictly invaildated? Like, the server keeps track of which file descriptors the various wine processes have cached, and if a process closes or performs some locking operation on a file descriptor, all the other wine proceses that are using that file descriptor are explictly notified. This way processes can assume a file descriptor is valid unless told otherwise... would this be any better performance-wise? Does it fit in to the wineserver architecture nicely? ;) -Ryan -- ------------------------- bodnar42(a)bodnar42.dhs.org ICQ #32862574 -------------------------

March 6, 2001

Re: Wineserver semantics

by Alexandre Julliard

Waldek Hebisch <hebisch(a)math.uni.wroc.pl> writes: > There is ongoing disscusion on how to seed up the wineserver. > So I have question concerning correctness of corrent implementation. > Namely, for reading or writing files I have not found any locking in > wineserver when issuing file descriptor to clients. On the other > hand the client closes file descriptor just after use, and also > disscusion in the group suggests that client is supposed to have > exclusive acces to file. So I would like to know what is the case: > 1) client is allowd to cache the descriptor > 2) current implementation depends on winning a race > 3) I missed locking in wineserver I'm not sure what you mean by 'exclusive access to the file'. If you mean file locking then this is not implemented, so there cannot be any race ;-) Currently the client is allowed to cache the descriptor, but before each read/write it checks with the server that the cache is still valid. There is a race that the handle can be modified between the check and the actual read, this will cause either a bad handle error or a read from the wrong file; but this is no different from what happens under Windows if the client is manipulating handles concurrently with a ReadFile. -- Alexandre Julliard julliard(a)winehq.com

March 6, 2001

Re: winelauncher patch

by Ove Kaaven

On Tue, 6 Mar 2001, Jeremy White wrote: > What was wrong with the previous implemenation? > Are you getting a $0 value that doesn't include > the path? For some reason I did at the time I tried, yes. Doesn't seem to happen anymore, but it's probably not portable (i.e. a bashism?) to assume that $0 is path-expanded anyway, is it? If "which" is a problem when $0 contains a path, just change it to something like if [ "$0" = `basename $0` ] then argv0_path=`which "$0"` else argv0_path="$0" fi or whatever.

March 6, 2001

Re: winelauncher patch

by Jeremy White

Ove, I have in fact determined why I did not use which: On Suse (and Caldera, I believe), which /usr/bin/wine returns an error string, making the whole script go straight down the drain. What was wrong with the previous implemenation? Are you getting a $0 value that doesn't include the path? In all of the test cases I have, invoking wine seems to bring in a $0 that includes enough of the path for the find logic to work. Jer > Hunk 2: > real_name=`find $0` don't find anything if the user typed "wine" or > something, wine is in /usr/bin, which is in PATH, but the cwd is ~... > rather run it through `which $0` first. Also, the symlink it's reading > don't have to be absolute (my symlinks are relative), deal with that. > > -real_name=`find $0 -type l -printf "%l\n"` > +argv0_path=`which $0` > +if [ -z $argv0_path ] ; then > + argv0_path=$0 > +fi > + > +real_name=`find $argv0_path -type l -printf "%l\n"` > if [ ! $real_name ]; then > - real_name=$0; > + real_name=$argv0_path > +elif [ ! -x $real_name ]; then > + real_name=`find $argv0_path -printf "%h\n"`/$real_name > fi > + > argv0_dir=`find $real_name -printf "%h\n"` > > if [ -z $argv0_dir ] ; then > @@ -130,7 +138,7 @@ > WINESERVER=$WINEBIN/server/wineserver > fi

March 6, 2001

Wineserver semantics

by Waldek Hebisch

There is ongoing disscusion on how to seed up the wineserver. So I have question concerning correctness of corrent implementation. Namely, for reading or writing files I have not found any locking in wineserver when issuing file descriptor to clients. On the other hand the client closes file descriptor just after use, and also disscusion in the group suggests that client is supposed to have exclusive acces to file. So I would like to know what is the case: 1) client is allowd to cache the descriptor 2) current implementation depends on winning a race 3) I missed locking in wineserver -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

March 6, 2001

Re: Speeding up wineserver syncronization objects with shared memory

by Alexandre Julliard

David Howells <dhowells(a)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(a)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(a)winehq.com

March 6, 2001

Re: RFC: client side implementation of async I/O

by Alexandre Julliard

Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > The patch can be further optimised, for example by keeping active asyncs in a > seperate list from inactive asyncs. i think it is more efficient because the > number of server calls and context switches is reduced. Reducing the number of server calls but making them more expensive is not necessarily a gain. Show me the numbers... > What i'm more interested in is whether having waiting clients running > concurrently with wineserver and those clients waking themselves from wait is > a good idea. I'm not sure it's a good idea, particularly if we want to support signals (which I think would be a good thing since it allows getting rid of the service thread). > Similarly, we could create a client side file handle cache that is alerted by > the wineserver when it becomes invalid. Before each fd is used, the cache > implementation would poll on the wineserver communication fd to confirm the > cache is valid, which would further improve the speed of file I/O. (a single > poll vs. a full server call) You'll probably still need a server call to find out about file locks at some point. And again you'll get in trouble if you want to support signals. -- Alexandre Julliard julliard(a)winehq.com

March 6, 2001