Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> That's *exactly* what I'm proposing: the speed critical part (the
> request mechanism, since it is used for all server calls) in the
> kernel, all the rest in user space.
But the time and CPU usage overhead comes from the context switches and the
waiting for the "other" process to be scheduled.
We can improve the client memory access mechanism to reduce the whole thing to
only two context switches, but they still impose a severe penalty.
> Obviously I'm not suggesting that we add these two functions as system
> calls; this is only the conceptual interface. The actual
> implementation should probably be based on file descriptors; basically
> it is a kind of pipe with slightly different semantics (you could even
> achieve most of that with normal pipes, but you'd need to always
> transfer 4096 bytes to keep the buffer full which would be a bit
> slow).
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.
A better way to do this is just to pass an address in the clients VM and have
the server access it directly.
David Howells
