By: Howard Chu (hyc.delete@this.symas.com), May 17, 2006 2:54 am
Room: Moderated Discussions
David Kanter (dkanter@realworldtech.com) on 5/16/06 wrote:
---------------------------
>AnalGuy (AnalGuy@yahoo.com) on 5/16/06 wrote:
>---------------------------
>>Why are you talking about distributed algorithms, we are not discussing Distributed
>>Systems, we are just discussing Microkernel and Monolothic >kernels.
>
>Well, I think the discussion has a lot to do with the theory behind mono versus
>micro. I'm not an OS developer, but my understanding is that ukernels need to have
>a lot of message passing between different blocks of software, whereas mono kernels
>simply share regions of memory. In many respects, this seems to be similar to shared
>memory versus clustered computing. So distributed algorithms would be useful for ukernels.
>
Sometimes the border is pretty fuzzy. When "message passing" merely consists of passing a pointer to an argument block around between code modules, it doesn't look a lot different from pushing arguments onto a stack and passing a frame pointer around. This is a pretty standard model in graphical window systems, particularly on register-starved machines (like x86) that don't usually pass a lot of parameters in registers. This is also the message passing model used in SVR4 STREAMS and Windows WDM drivers (which are pretty much a ripoff of STREAMS modules, as I recall).
But even within a single machine, the framework for queueing messages and such can get pretty expensive. About 12 years ago I was working on an AppleTalk stack written by Pacer software, implemented as individual STREAMS modules for each protocol. It was a pretty text-book implementation of the STREAMS programming model, and frankly its performance was anemic. I rewrote the DDP/ADSP/ATP stack as a single module, while still exporting the individual protocols' STREAMS entry points (But allowing ATP to call directly into DDP etc rather than going through three layers of STREAMS queues) and got as much as a 5x performance increase (depending on the particular machine), without sacrificing any compatibility or concurrency. Abstraction layers are a convenient mental tool for decomposing problems into manageable chunks, but they should only be a conceptual design tool. They cost too much when carried *literally* into implementation land.
The idea of microkernels is valuable, as a conceptual design perspective. The ability to isolate functionality makes it much easier for you to define it and develop it. But just because you define tightly-demarcated interfaces doesn't mean you should always implement that way. E.g., if you want to operate a cluster, with uniform APIs for invoking local or remote modules transparently: you could use a message-passing API locally, and pass message block pointers around to local modules, or you could use a traditional procedure-call oriented API, and turn argument lists into message blocks for remote modules. Ultimately what you choose for the visible API says nothing about how it must be implemented underneath.
>Again, I'm not an OS developer, so someone correct me if I'm spouting nonsense.
---------------------------
>AnalGuy (AnalGuy@yahoo.com) on 5/16/06 wrote:
>---------------------------
>>Why are you talking about distributed algorithms, we are not discussing Distributed
>>Systems, we are just discussing Microkernel and Monolothic >kernels.
>
>Well, I think the discussion has a lot to do with the theory behind mono versus
>micro. I'm not an OS developer, but my understanding is that ukernels need to have
>a lot of message passing between different blocks of software, whereas mono kernels
>simply share regions of memory. In many respects, this seems to be similar to shared
>memory versus clustered computing. So distributed algorithms would be useful for ukernels.
>
Sometimes the border is pretty fuzzy. When "message passing" merely consists of passing a pointer to an argument block around between code modules, it doesn't look a lot different from pushing arguments onto a stack and passing a frame pointer around. This is a pretty standard model in graphical window systems, particularly on register-starved machines (like x86) that don't usually pass a lot of parameters in registers. This is also the message passing model used in SVR4 STREAMS and Windows WDM drivers (which are pretty much a ripoff of STREAMS modules, as I recall).
But even within a single machine, the framework for queueing messages and such can get pretty expensive. About 12 years ago I was working on an AppleTalk stack written by Pacer software, implemented as individual STREAMS modules for each protocol. It was a pretty text-book implementation of the STREAMS programming model, and frankly its performance was anemic. I rewrote the DDP/ADSP/ATP stack as a single module, while still exporting the individual protocols' STREAMS entry points (But allowing ATP to call directly into DDP etc rather than going through three layers of STREAMS queues) and got as much as a 5x performance increase (depending on the particular machine), without sacrificing any compatibility or concurrency. Abstraction layers are a convenient mental tool for decomposing problems into manageable chunks, but they should only be a conceptual design tool. They cost too much when carried *literally* into implementation land.
The idea of microkernels is valuable, as a conceptual design perspective. The ability to isolate functionality makes it much easier for you to define it and develop it. But just because you define tightly-demarcated interfaces doesn't mean you should always implement that way. E.g., if you want to operate a cluster, with uniform APIs for invoking local or remote modules transparently: you could use a message-passing API locally, and pass message block pointers around to local modules, or you could use a traditional procedure-call oriented API, and turn argument lists into message blocks for remote modules. Ultimately what you choose for the visible API says nothing about how it must be implemented underneath.
>Again, I'm not an OS developer, so someone correct me if I'm spouting nonsense.
Topic | Posted By | Date |
---|---|---|
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 04:41 PM |
Hybrid (micro)kernels | S. Rao | 2006/05/08 06:14 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/08 06:16 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 07:21 PM |
Hybrid (micro)kernels | nick | 2006/05/08 07:50 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 01:26 AM |
There aren't enough words... | Rob Thorpe | 2006/05/09 02:39 AM |
There aren't enough words... | Tzvetan Mikov | 2006/05/09 03:10 PM |
There aren't enough words... | Rob Thorpe | 2006/05/15 12:25 AM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/09 11:17 AM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 04:05 PM |
Hybrid (micro)kernels | rwessel | 2006/05/08 11:23 PM |
Hybrid kernel, not NT | Richard Urich | 2006/05/09 06:03 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 07:06 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 07:40 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 08:30 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 09:07 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 09:36 AM |
Linux vs MacOSX peformance, debunked | _Arthur | 2006/05/18 07:30 AM |
Linux vs MacOSX peformance, debunked | Rob Thorpe | 2006/05/18 08:19 AM |
Linux vs MacOSX peformance, debunked | Anonymous | 2006/05/18 12:31 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 08:16 AM |
Hybrid kernel, not NT | Andi Kleen | 2006/05/09 02:32 PM |
Hybrid kernel, not NT | myself | 2006/05/09 03:24 PM |
Hybrid kernel, not NT | myself | 2006/05/09 03:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/09 05:26 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 08:06 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 01:35 AM |
Hybrid kernel, not NT | nick | 2006/05/13 04:40 AM |
Hybrid kernel, not NT | Brendan | 2006/05/13 09:48 AM |
Hybrid kernel, not NT | nick | 2006/05/13 07:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 09:51 PM |
Hybrid kernel, not NT | nick | 2006/05/14 05:57 PM |
Hybrid kernel, not NT | Brendan | 2006/05/14 10:40 PM |
Hybrid kernel, not NT | nick | 2006/05/14 11:46 PM |
Hybrid kernel, not NT | Brendan | 2006/05/15 04:00 AM |
Hybrid kernel, not NT | rwessel | 2006/05/15 07:21 AM |
Hybrid kernel, not NT | Brendan | 2006/05/15 08:55 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/15 09:49 AM |
Hybrid kernel, not NT | nick | 2006/05/15 04:41 PM |
Hybrid kernel, not NT | tony roth | 2008/01/31 02:20 PM |
Hybrid kernel, not NT | nick | 2006/05/15 06:33 PM |
Hybrid kernel, not NT | Brendan | 2006/05/16 01:39 AM |
Hybrid kernel, not NT | nick | 2006/05/16 02:53 AM |
Hybrid kernel, not NT | Brendan | 2006/05/16 05:37 AM |
Hybrid kernel, not NT | Anonymous | 2008/05/01 10:31 PM |
Following the structure of the tree | Michael S | 2008/05/02 04:19 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 05:31 AM |
Following the structure of the tree | Michael S | 2008/05/02 06:02 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 06:48 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 09:14 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 10:05 AM |
LOL! | Dean Kent | 2008/05/02 10:33 AM |
Following the structure of the tree | anonymous | 2008/05/02 03:04 PM |
Following the structure of the tree | Dean Kent | 2008/05/02 07:52 PM |
Following the structure of the tree | Foo_ | 2008/05/03 02:01 AM |
Following the structure of the tree | David W. Hess | 2008/05/03 06:54 AM |
Following the structure of the tree | Dean Kent | 2008/05/03 10:06 AM |
Following the structure of the tree | Foo_ | 2008/05/04 01:06 AM |
Following the structure of the tree | Michael S | 2008/05/04 01:22 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 05:19 PM |
Microkernel Vs Monolithic Kernel | Kernel_Protector | 2006/05/09 09:41 PM |
Microkernel Vs Monolithic Kernel | David Kanter | 2006/05/09 10:30 PM |
Sigh, Stand back, its slashdotting time. (NT) | Anonymous | 2006/05/09 10:44 PM |
Microkernel Vs Monolithic Kernel | blah | 2006/05/12 08:58 PM |
Microkernel Vs Monolithic Kernel | Rob Thorpe | 2006/05/15 01:41 AM |
Hybrid kernel, not NT | AnalGuy | 2006/05/16 03:10 AM |
Theory versus practice | David Kanter | 2006/05/16 12:55 PM |
Distributed algorithms | Rob Thorpe | 2006/05/17 12:53 AM |
Theory versus practice | Howard Chu | 2006/05/17 02:54 AM |
Theory versus practice | JS | 2006/05/17 04:29 AM |
Play online poker, blackjack !!! | Gamezonex | 2007/08/16 01:49 PM |
Hybrid kernel, not NT (NT) | atle rene mossik | 2020/12/12 09:31 AM |
Hybrid (micro)kernels | philt | 2006/05/14 09:15 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 08:20 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 11:56 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 01:22 AM |
Hybrid (micro)kernels | rwessel | 2006/05/16 11:23 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/17 12:43 AM |
Hybrid (micro)kernels | rwessel | 2006/05/17 01:33 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/19 07:51 AM |
Hybrid (micro)kernels | rwessel | 2006/05/19 12:27 PM |
Hybrid (micro)kernels | techIperson | 2006/05/15 01:25 PM |
Hybrid (micro)kernels | mas | 2006/05/15 05:17 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 05:39 PM |
Hybrid (micro)kernels | Colonel Kernel | 2006/05/15 09:17 PM |
Hybrid (micro)kernels | Wink Saville | 2006/05/15 10:31 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 10:08 AM |
Hybrid (micro)kernels | Wink Saville | 2006/05/16 09:55 PM |
Hybrid (micro)kernels | rwessel | 2006/05/16 11:31 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 12:00 PM |
Hybrid (micro)kernels | Brendan | 2006/05/16 01:36 AM |
Hybrid (micro)kernels | Paul Elliott | 2006/09/03 08:44 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/09/04 09:25 AM |
Hybrid (micro)kernels | philt | 2006/05/16 12:55 AM |
Hybrid (micro)kernels | pgerassi | 2007/08/16 07:41 PM |
Another questionable entry on Wikipedia? | Chung Leong | 2006/05/18 10:33 AM |
Hybrid (micro)kernels | israel | 2006/05/20 04:25 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/22 08:35 AM |