Re: More syscall messaging commits, and some testing code as well.

["Eric J. Chet" <ejc@xxxxxxxxxx>]

On Tue, 12 Aug 2003, Matthew Dillon wrote:

>     Well, I don't think it really needs to be that complex.  Complex
>     algorithms create large overheads and system calls need to remain fast
>     and efficient.  All we really need is a way to tell a userland thread
>     scheduler to fallback to an older mechanism (like polling) when it
>     exceeds the concurrent system call resource limit.  This would only occur
>     in an extreme case since our kernel will be able to support far more
>     concurrent syscall messages then other designs.

I believe I understand where your going with this now.  Also I guess we
don't need a concurrent queue implementation with the lease approach.

>
>     If we assume the kernel system call messaging overhead is around
>     256 bytes per message, then supporting 100000 concurrent system
>     calls would only eat around 25MB of ram.   In otherwords, no drastic
>     'solution' to the problem is needed, just something that prevents the
>     system and the programs running on the system from destabilizing if
>     they happen to hit the limit.

So the odds of that happening are very slim, so we optimize for the happy
path.  On those exception cases we take the hit with a poll from the
userland scheduler.  Once the userland scheduler is notified that the
limit has been reached, could we instead have a upcall to the userland
scheduler when the queue length drops below some water mark, until
that upcall happens the userland scheduler won't make any systems calls?


Eric

>
> 					-Matt
> 					Matthew Dillon
> 					<dillon@xxxxxxxxxxxxx>
>
> :Hello Matthew
> :
> :     So we need a bounded concurrent queue to register the
> :message with.  There are concurrent queue designs which allow you to
> :push and pop without contention as long as you have at least one item
> :in the queue.  When the queue is at it's limit I expect the push() will
> :block for that call?  How should we handle the administration of
> :the bounded queue size, we could use a sysctl for a global limit.
> :
> :Would we ever want to use a class based bounded queue and use the user pid
> :as the class?  We can then use 'ulimit' to set the bounded queue size on a
> :per process basis.  After we get global limits working, this would be a
> :good exercise to allow process based limits, we could use a sysctl to turn
> :on this feature.
> :
> :Going down this road gives us a lot to play with, we could also implement
> :a priority based queue and implement static and/or dynamic priorities to
> :syscalls based what is going on in the kernel.
> :
> :A lot to think about, I will take a look at your work.
> :
> :Regards,
> :
> :Eric Chet
>

Regards,

Eric Chet