> I'd advocate the opposite approach: rather than move everything in the
> kernel, except for the few things that are too complicated, I'd
> suggest moving to the kernel only the strict minimum necessary to
> achieve acceptable performance. We don't need to beat Windows at raw
> mutex performance, and maintaining two complete implementations of the
> server is not realistic IMO.
I don't think it is possible to do that in a sane way.
Everything that is speed critical should be in kernel,
things that are not should not. Trying to do it
some other way is doomed to failure I think.
> I think what we need is:
>
> - on the client side, a wake_server_and_sleep() call that combines the
> write()+read() on the socket in a single syscall.
>
> - on the server side, a wake_client_and_wait_for_next_one() that wakes
> the client whose request was last processed, and waits until some
> other client sends a request.
Urk... Good luck getting that into the kernel.
I think hell will freeze over before that happends.
One thing that Linus Torvalds absolutely hate is a random collection of
API:s. He wants them to have some sort of concept behind them.
I fail to see the concept behind the API:s above.
The use yes, but not any concept.
Also note that they also have the potential to be misused in a DOS
(Denial of Service) attack unless carefully implemented and not
unlikely with a large performance cost.
> This should enable doing a complete server round-trip with only two
> syscalls (one in the client one in the server), and avoid any
> unnecessary context switch.
True, however the abillity to selectively choose a specific process
to yield to doesn't fit very well with the CONCEPT of a time sharing
system.
It is possible yes. BeOS does that to some extent, so it makes some
sense and give great latencies for some things.
However try to convince Linus doing that with Linux.
I bet you will fail.
> If we combine this with an efficient way to read/write the client
> memory space from the server, I think we should be able to achieve
> good performance while still reusing nearly all the existing code.
>
> And if the mechanism is small enough and generic enough, we can even
> hope to have it included in the standard kernel, which I doubt would
> ever be possible with the complete server kernel module.
Primary we want to reserve a syscall.
I'm not sure we will want to have it
included in the kernel at all.
Perhaps somewhere post Wine 1.0 but not now.
When we have come far enough we can affort
supporting two versions, since neither are
likely to change very much.
