More syscall messaging commits, and some testing code as well.
dillon at apollo.backplane.com
Tue Aug 12 11:35:01 PDT 2003
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.
<dillon at xxxxxxxxxxxxx>
: 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.
More information about the Kernel