Brendan (btrotter@gmail.com) on 5/13/06 wrote:
---------------------------
>Hi,
>
>nick (anon@anon.com) on 5/13/06 wrote:

>>Great now your scalability sucks, and you can do this with
>>a monolithic kernel anyway as Linus points out.
>
>The message queues are only locked when messages are being added or removed. I
>guess it does depend on how the messaging is done - synchronous messaging would probably suck for scalability.

No, it would suck. You're about 10 years behind: lock
contention doesn't hurt scalability any more, cacheline
contention does.

>>>Also, a micro-kernel is often small enough that the equivelent of a "big kernel
>>>lock" is practical, meaning you could have one lock in the entire system in addition
>>>to any "processes specific" locks, and no other locks.
>>
>>I don't know what systems that thing would run on, but it
>>wouldn't be any big ones, that's for sure.
>
>That depends what the OS is designed for and how fast the slowest kernel function is.

The microkernel handles scheduler, interrupts, IPC, and
queueing messages to servers? And it has a big kernel lock?
Then scalability sucks, full stop.

>
>>>Another potential advantage is NUMA systems, where you can set the CPU affinity
>>>on a device driver so that it's always run on a CPU that is "close" to the I/O controller
>>>used by the device. This doesn't apply to things like
>>
>>No, this is not. Because if the data is coming from / going
>>to somewhere off node, you must send it across nodes anyway.
>>And now you *also* have control information (messages) going
>>across nodes as well.
>
>For control information you've got a choice - access the control data across nodes,
>or access the device driver code and it's local state across nodes. Unless everything
>(control data, code and state) is on the same node it can't be "perfect" regardless
>of what you do (for all kernel designs).

That isn't a choice, that is a restriction!