> David Howells <David.HowellsÉnexor.co.uk> writes:
>
> > This is fairly pointless... the Linux system call overhead
> isn't all that
> > major - issuing separate send & receive calls loses you
> very little. Beyond
> > the fact that the server may be busy doing something else,
> the real killer is
> > the pair of context switches and the fact that there is no
> guarantee that the
> > server will immediately be scheduled after the client, and
> the client again
> > after the server.
>
> I'm not so sure. I did a few tests with using signals and ptrace as a
> communication mechanism instead of sendmsg/recvmsg, and the total time
> for a server round-trip got reduced by half. I don't know how much of
> that is because of extra context switches or of sendmsg overhead, but
> there is certainly a large potential to improve things here.
Agreed. It is not unlikely that you will find some other user space
solution using existing syscalls that are faster.
However if you think you will get some special magical syscall, that will
enable us to keep most of the code in userspace, included in the Linux
kernel is very unlikely even given it will work for Wine both in theory
and in pratice. I fear it will give unwanted side effects for other
applications. For starters you will have a hard time designing something
that doesn't need a scheduler supporting selective yield.
Of course I'm hope I'm wrong, but I fear I'm not.
> And
> before deciding to move everything in the kernel I think it would be a
> good idea to investigate what we can achieve with less radical
> solutions.
First of all we are not talking about moving everything to the server.
Just some speed critical things. Beside we need to continue maintaining
a user space for non-Linux platform and for Linux users not wanting or
knowing how to install a custom Linux kernel. They will use the
distribution default kernel with Wine support.
Personally I see the kernel space wine server more as a market gimmick
than something really usefull. Very few people are likely to run
applications making heavy use of kernel object. Even applications doing
heavy file IO are unlikely to be run under Wine. Wine is IMHO mainly
for running desktop applications.
I primary want to be able to tell people that says Wine is slow:
"Use the kernel space wine server". I do not intend to use it
myself for anything other than tests. I don't run any Windows
application, whether under Wine or not, where I'm likely to
notice any different.
> > Indeed, it may be necessary to swap the server back in,
> depending on system
> > load.
>
> Yes of course; but if the system is loaded I prefer to have the server
> swapped out than having it locked forever in unswappable memory like
> with your solution.
Agreed. David gave a silly example. If the Wine server is not
heavily used it only matter very little if it is swapped out
or not. If it is heavily used and is still swapped out,
it can only mean that some other process or process are
even more heavily used and probably need that memory better
than the Wine server.
> > Not nice... Imagine you want to just grab a mutex... you'd
> have to transfer 4K
> > of data each direction, the vast majority of which would be
> totally wasted. I
> > have to agree with Patrik again, sendmsg+recvmsg are better
> options there.
>
> You missed the point; of course transferring 4K of data is too slow,
> which is exactly why we don't do this now. But if we had a mechanism
> where we could avoid the 4K transfers, then it would help a lot. Yes
> there is sendmsg but it has some unnecessary overhead (memory
> allocations etc.)
You can't have everything. It is not unreasonable to assume that
the best place to implement NT kernel objects is in the Linux kernel
especially given the shared word "kernel". :-)
Seriously, as I said above, I consider a Linux kernel Wine server
nothing more than a marketting gimmick. I would very much prefer
the user space Wine server to be maintainable and robust rather
than fast. 99.99% of all application that are likely to be run
under Wine will not care if mutexes are 900% slower as long as
they have the correct semantics. GUI application doesn't usually have
worker thread (needing syncronation) unless they do something that
takes so long time that user will notice without the worked thread.
The current Wine implementaton are capable doing syncronation
in less that 1 ms (about 1600 times per second) according to David
which means that the extra delay will drown in the time that the
worker thread are likely to use.
Therefore I suggest that we doesn't try to be clever in the
user space server but rather make it possible to cooperate
with the kernel space server if and when available.
Just do a runtime check when the server and the client is run.
