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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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.

    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.

					-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