Patrik Stridvall <[EMAIL PROTECTED]> wrote:
> 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.
Plus, I don't think you can do selective yielding at the moment. You might be
able to get around the DoS attack by having the scheduler limit the amount of
time you can trade to the remainder of your timeslice, after which the process
to which you yield gets scheduled out anyway. But it sounds horribly complex.
> 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.
Agreed.
> 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.
Agreed... but you still have to pay the penalty on context switches.
> IMHO putting the speed critical NT kernel object in the kernel
> is a much better and more realistic solution.
Also agreed. The kernel has good support for synchronisation, providing a
wealth of types of synchronisation object.
David Howells
