> Patrik Stridvall <psÉleissner.se> 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.
What I meant is that NT kernel objects that are speed critical
should be in the kernel (like mutexes for example). Lets call
that vertical separation.
You are trying to do a separtion in the other horizontal direction.
That is doomed to failure I think. You will have to have very
specialized "syscall":s do to that, which I predict will not
be accepted in the main kernel.
> > > - 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.
>
> 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).
Well. You have sendmsg and recvmsg that you use now. :-)
Seriously see below.
> > 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.
>
> I must have missed something here. Could you explain where you see a
> problem, and what performance cost it would cause?
Nothing specific, just a general feeling that some sort of selective
yielding is not a good idea and in order to avoid DoS something
not unlikely costly must be done to have a fair scheduling.
> > > 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.
>
> You don't have to do that; all you need is to ensure that client and
> server are not runnable at the same time to avoid unnecessary context
> switches.
Regardless of what syscalls you have, if you want good latency you must
have a guarantee that in average that kernel will schedule the server
after the client call as well as the reverse.
For a lightly loaded machine this is likely to happend automatically
since few other processes want to run. But for a heavily loaded machine
you probably must have some sort of selective yield otherwise you will
get very bad latancy when other process get time slices in between.
I'm not a kernel expert but I have a general feeling that you will
never get good performance unless the kernel gives you some kind
of selective yield guarantees which is not unlikely to be costily
for scheduler.
IMHO putting the speed critical NT kernel object in the kernel
is a much better and more realistic solution.