wine-devel

wine-devel@winehq.org

5 participants
84465 discussions

Re: RFC: client side implementation of async I/O
by Alexandre Julliard 11 Mar '01

11 Mar '01

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

2 1

Re: [PATCH] deferred trace
by Alexandre Julliard 10 Mar '01

10 Mar '01

gerard patel <gerard.patel(a)asi.fr> writes: > This implements a way to not output the debug trace to disk until the > user hits Alf + F12. The goal is to avoid too big trace files. I think it would be much better to do that with a small external program that you pipe the debug output into. This way you can have much more flexibility, and you don't need to hardcode a specific key that some apps may need. -- Alexandre Julliard julliard(a)winehq.com

1 0

Palette managing
by kenon＠go2.pl 10 Mar '01

10 Mar '01

Hi In file windows/painting.c in function RealizePalette16 I found that line 1713: if (hWnd) SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); broke some applications . When I comment it out - every things work well, but when I leave it some child-windows are displayed in improper place. I think this message should be sent only when used entry in COLOR_sysPal is replaced by new one (function X11DRV_PALETTE_SetMapping in line 907 when index == -1). Maciek Kaliszewski

1 0

Re: Edit control notification fix
by Andreas Mohr 09 Mar '01

09 Mar '01

On Fri, Mar 09, 2001 at 03:52:56PM +0800, Dmitry Timoshkov wrote: > Hello. > > Andreas Mohr privately reported that some old 16-bit installer > started to not update its edit control after my patch entitled > "Do not notify parent of the Edit control on WM_SETTEXT when Edit > is part of the ComboBox." Investigation has shown that installer > has its main dialog window defined in resources, and DIALOG_GetControl16() > gets edit control with style ES_COMBO (0x200) defined there. > My first attempt to fix the trouble was to simply mask out not > allowed styles in the DIALOG_GetControl16(): i.e. for edit control > do style &= ~ES_COMBO. That hack cured the application, but Andreas Well, that's not exactly true. You did not do it "for edit control". You did it for *all* controls in DIALOG_GetControl16() (at least in the patch you sent me). That's why I objected. I just had to :) > didn't like that approach. After some thinking, I added yet another > test into my "Edit Control Test Suit". And here is the result of it. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Do not send notification to parent of an edit control, > if parent is a child window. Remove old and not correct patch. OK. I can't really judge whether that's correct, as I'm not too much into these kinds of things. Hopefully it's correct :) Thanks again, Andreas Mohr

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 08 Mar '01

08 Mar '01

David Howells <dhowells(a)cambridge.redhat.com> writes: > Not so... The file offset must also be page aligned! OK, this has apparently changed in kernel 2.4; in kernel 2.2 block size alignment is enough. That's unfortunate, but I guess it was necessary to support large files or memory sizes. Then yes, in 2.4 your patch will be more useful. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 08 Mar '01

08 Mar '01

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

2 2

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 08 Mar '01

08 Mar '01

Gavriel State <gav(a)transgaming.com> writes: > Looking at the kernel sources, it appears to be page-alignment, not > filesystem block size that mmap needs to match. Rereading old wine-devel > archives, it appears that the notion that the filesystem block size is > involved is either from a very old kernel, or a misreading of some kernel > comments. Page alignment is needed for the address in memory, not for the offset inside the file on disk; since section virtual addresses in PE files are always page-aligned the memory address is never a problem. The only problem comes from the alignment of the data inside the PE file, and this is where we only need block-size alignment to make mmap possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard 07 Mar '01

07 Mar '01

David Howells <dhowells(a)cambridge.redhat.com> writes: > 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. I suspect we are doing more than two switches (though I haven't proved it), which is why I think there is a margin for improvement. You'll obviously always have the context switch cost unless everything is in the kernel. > 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. Yes, we'll need to store the locks in the server and check them before each read/write (and probably also release them afterwards if necessary). There may be some optimisations possible, but we should probably do it the easy way first. > 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. I don't see why. I'm not suggesting keeping the current socket stuff, just reusing the structures. So basically instead of passing the address of the stack arguments (which is really ugly IMO) to your ioctl, you pass one of the server request structures. This allows your changes to be localized to wine_server_call and doesn't require changing any of the routines that make server calls. Obviously you'd need some more changes for a few calls like ReadFile/WriteFile, but most operations could switch to your mechanism without needing any change. You simply cannot require people to recompile all of Wine to use your module. > > 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... I don't know exactly, there are many ways of doing it; you can have a specialized fifo, a network protocol, an ioctl, etc. Basically any mechanism that ensures that we do the strict mimimum number of context switches and schedule() calls for a server call. And probably also a way to transfer chunks of memory from the client address space so that we don't need the shared memory area. > 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): Actually the file alignment doesn't need to be 4096, it needs to match the filesystem block size. On a FAT filesystem the block size is 512 so Linux will happily mmap every section. On a 1k-block ext2 fs it will be able to mmap about 50% of them. > 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. Only if the dll cannot be loaded at the preferred address, which shouldn't happen too often. I'm not saying your patch is useless, but I doubt the gain is as large as you seem to think. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells 07 Mar '01

07 Mar '01

Gavriel State <gav(a)transgaming.com> wrote: > As it stands, your approach won't be useful for general Wine usage until > you've got *everything* done. True. But I think there are valid reasons for doing it this way. One major problem is handles. Either the kernel must allocate all handles, or userspace must allocate all handles. Take something like the implementation of DuplicateHandle() - dead easy really in kernel space, including duplication to another process. If userspace tells the kernel to use handle X for a mutex, say, and handle Y for a semaphore, then userspace still has to go to atomic management code to (a) allocate a handle, and (b) access a handle. And to implement cross-process duplication, you either need some sort of interrupt & IPC mechanism, or an external process (the wineserver). This being the case, you lose any gains by putting the stuff in-kernel. Alternatively, if userspace is allowed to implement arbitrary handles that are allocated by the kernel, then the kernel waiting mechanism can get a little tricky. However, that said, for non-waitable objects, this might not be so bad. In fact, I'm planning on implementing the registry access handles this way and may well do some of the process and thread control this way too. Furthermore, the kernel would have to be given object handles not object pointers, otherwise you have a gaping security hole. And another major problem is context switches... they are horribly expensive really. They currently make Wine with at least 20 times the system call latency that the kernel method is capable of. > And then there will be boatloads of debugging to do. Perhaps not as much as you think... I'm doing as much debugging as I can as I go along, just making sure the kernel objects work as I'd expect (not necessarily the same thing, true, as having "compatible" behaviour). > If there's any way that you can implement your kernel module more within the > context of the existing server architecture - replacing objects on a piece > by piece fashion rather than all at once - that might make it easier to > adopt. See above for why the piece-by-piece method is difficult. One alternative would be to invent a new network protocol (say AF_WINE), but that again requires a complete implementation before it is really useful. > For example, you might try implementing the core object/handle management > and waiting code in the kernel module, and have the wine server rely on the > kernel module for that low-level functionality. By this, do you mean actually having the wineserver process talk to the kernel module on behalf of the Wine application? > Waiting for objects would be implemented on the client side through a call > to the kernel module. That's what I'm currently doing, though it's not fully implemented yet. > When something needs to be done with an object, we would call either the > wineserver or the kernel module, depending on how that object is > implemented. > For example, you could do mutexes entirely within the kernel module, but > leave file objects on the wine-server side initially. 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. I suspect it can't really be done otherwise, particularly if ZwCloseObject (or whatever it is called) is implemented, since this allows handles in another process to be closed. Actually, I've done a fair amount of the file object stuff... Most of it involves mapping down to a "struct file *", which is how the kernel views files, and then invoking appropriate kernel method. > 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. > One thing I've been wondering that you might be able to answer is this: > exactly why is the current Wine Server architecture so slow? Is it just the > context switching? 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. Also, you have to bundle lots of data through AF_UNIX network packets and/or copy lots of data into and out of _shared_ memory without killing other threads. One of the problems with the context switch is that you have to flush all the CPU caches, muck around with the MMU and execute scheduling algorithms. > Is it that the kernel isn't giving the wineserver a high enough priority > once the client blocks after having written to the socket? I don't think priority has anything much to do with it. A more convenient scheduling algorithm might help a little, though. > Is it other socket overhead (routing, perhaps)? Simply speeding up the > communications path between the clients and the server would remove the need > for most of the kernel level services. I don't think so... To communicate with the wineserver you have to use some sort of waitable UNIX object (ie: a socket, a pipe, or a SYSV semaphore or message), do busy waiting (& kill your CPU), or send signals (context switch _and_ signal overhead). To do it without a wineserver (ie: using shared memory) is also tricky... You have to be able to, for instance, recover from processes going away without releasing mutexes. > Also, just FYI, the PE image mapping work is nice, but isn't likely to affect > speed all that much, since Wine can just mmap in most PE images created with > recent compilers. WordPerfect, for example, launches in around 10-12 seconds > on my machine (down from 45-60 seconds before the mmaping). I can't imagine > that doing the fixups when paging instead would do too much better. 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. Plus, it should be even quicker launching because fixups don't have to be done unless they're necessary. You certainly don't have to go through an fixup a few tens of megs of DLL. Cheers, David

1 0

Re: Wineserver semantics
by Alexandre Julliard 07 Mar '01

07 Mar '01

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel