Was Moore's law, now something else, parallelism

[Jerry Feldman]

On 07/13/2010 02:40 PM, Mark Woodward wrote:
> On 07/13/2010 10:28 AM, Edward Ned Harvey wrote:
>  =20
>>> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On
>>> Behalf Of Mark Woodward
>>>
>>> Maybe its an OS issue? Like the RAID process described above, operati=
ng
>>> systems have to become far more modular and parallel to benefit.
>>>     =20
>>>      =20
>> You mean more modular and parallel than what?  They already support SM=
P (for
>> years since) and virtualization and hyperthreading...  How do you mean=
 more
>> modular?
>>   =20
>>    =20
> This is a complex discussion, to keep it simple I will use several vagu=
e=20
> generalities, so understand that I know there are threads used by the=20
> Linux kernel and there are no true absolutes here. That said, the=20
> problem with monolithic kernel design is that they are designed=20
> primarily and conceptually as an API library for applications. An=20
> application execs a kernel call, the function jumps into kernel code,=20
> executes the API code, and returns a value.
>
> In the multiple processor paradigm, a task will place its request in a =

> message queue which will be read by a user space process, that process =

> will execute the code, and place the result in the message. On a highly=
=20
> parallel system multiple CPUs/threads will be executing.
>
> While there is more work in the second example, the overall throughput =

> of the second example will be higher in a highly parallel system.
>  =20
>>   =20
>>    =20
>>> That
>>> whole user-space micro-kernel process stuff doesn't sound so useless
>>> now.  Monolithic/Modular kernels ruled as CPU cores were scarce.
>>>     =20
>>>      =20
>> They still rule now.  Is there some alternative that doesn't use a
>> monolithic or modular kernel?  I don't know of any other option...
>>   =20
>>    =20
> The point I'm making is that monolithic kernels will not perform as wel=
l=20
> as micro-kernel designs when there are many many CPUs.
>  =20
>
>
This is not entirely the case. The monolithic vs. micro kernel argument
has been around for many years. But, the central issues surround the
kernel data structures, such as memory, cache, I/O, and more. Some
system architectures allow the administrator to dedicate specific CPUs
and memory to an OS so that you can have multiple different operating
systems on the same physical system. But, when you get into the sharing
of resources, you run into the classic bottlenecks that exist whether
you have a monolithic kernel or a micro kernel. Years ago at a company
we were having discussions whether to (1) use Unix, (2) use QNX, or (3)
do it ourselves. QNX is essentially the type of OS that uses a micro
kernel with message passing. I have not looked at its architecture for
years.

Additionally, many things have complicated the kernel architecture. Bill
(or someone else) mentioned SMP. But also very important in the server
space is NuMA. Essentially you may have memory that is on the board as a
physical CPU in a multi-cpu system, but how does the kernel manage what
goes to that memory.

Basically, the nature of the processing can determine whether a
monolithic kernel performs better than a mico-kernel.  It all comes down
to resource management, and in multi-CPU, multi-memory you have a very
complex system, then add the cache.

Just one more thing, the classic monolithic Unix kernel had to have all
of its drivers preloaded into the kernel, normally by running the link
editor when building the closed-source kernels. Linux was similar where
most of the important drivers were precompiled into the kernel, but in
contrast, most drivers are dynamically loaded. So, you could argue that
Linux today is modular, but still has a monolithic-type of architecture.

But, no matter what kernel architecture it comes down to managing the
shared resources.

--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846