About exokernels...

[oscoder]

The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?

This depends on what you intend to achieve. An exokernel and the apps that run on it, has the *potential* to be far more efficient than a micro/monolithic kernel. *However* you have to take into account the inefficiency of using an under-researched design (will take a lot longer to design and implement), of developing custom libOSes, etc. Time spent writing software for an OS that uses radically different concepts to what the developer is used to is time that could be spent optimising code and ironing out bugs, so in the real world it is quite possible an exokernel would behave less efficiently. The increased efficiency in an exokernel comes from the kernel giving software a greater amount of control, of things the kernel would normally handle. This means that the software may do a better job than the kernel would have. But it is conceivable that the software will do a worse job.

Is there any book about exokernels (like the Tannenbaum's one but changing microkernel for exokernel)? I've searched but I haven't found anything.

That's ridiculous. That's like asking about a book on FAT. What's wrong with the papers and theses on the MIT webiste?

Is there any source of an exokernel? I've searched in the MIT webpage but I haven't found it.

The homepage of the website you are referring to only has a couple of paragraphs and you were unable to find it? Congratulations, you failed as a human being.

The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?

Let me rephrase this for you: "I have done absolutely no research and have no intention to do so but I am hoping someone on this forum will tell me how to be the best OS developer in the world in one paragraph." To get back to the real question, exokernels are not a type of kernel, they are a type of kernel interface.

Love4: could you please be less narky? I joined these forums because they were friendly. Noob bashing is really unnecessary - even if it's a stupid post, you don't have to read it.

[Solar]

The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?

The increased efficiency in an exokernel comes from the kernel giving software a greater amount of control, of things the kernel would normally handle.

Very important line, here. Under an exokernel, applications have the option to replace parts of what would be "OS territory" on other systems, e.g. the memory manager or file system, with something customized for their particular use.

This is a potential. If all your apps use default functionality only, it wouldn't make much of a difference whether there's an exokernel or something else under the hood.

could you please be less narky?

Always a worthy goal to strive for.

I joined these forums because they were friendly.

That, on the other hand, is somewhat optimistic.

[brain]

I joined these forums because they were friendly.

That, on the other hand, is somewhat optimistic.

i find these forums friendly to those who properly research before asking questions, which is always a good way to go about things (google it first )

[Rusky]

The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?

The increased efficiency in an exokernel comes from the kernel giving software a greater amount of control, of things the kernel would normally handle.

Very important line, here. Under an exokernel, applications have the option to replace parts of what would be "OS territory" on other systems, e.g. the memory manager or file system, with something customized for their particular use.

This is a potential. If all your apps use default functionality only, it wouldn't make much of a difference whether there's an exokernel or something else under the hood.

Definitely true. But it can still make a difference- one of MIT's research kernel projects benchmarked binary emulation of a BSD executable vs running it natively, and it was faster on the exokernel while using only the default BSD libOS because of optimizations enabled by the file system being in user space.

[Brendan]

Hi,

Definitely true. But it can still make a difference- one of MIT's research kernel projects benchmarked binary emulation of a BSD executable vs running it natively, and it was faster on the exokernel while using only the default BSD libOS because of optimizations enabled by the file system being in user space.

Could those same optimisations be done on BSD, and if they were would BSD have been faster than the exo-kernel (was the performance difference due to having an exo-kernel, or were they caused by implementation differences that have nothing to do with exo-kernels)?

Also, performance is only one metric. Another metric is fault resilience. For example, (for file systems) it's possible to improve performance by doing aggressive write caching, but end up with major data loss if there's a power failure or something. Did the exo-kernel sacrifice fault resilience for performance?

What sort of load/s were tested? Maybe they only tested huge sequential reads and found that the exo-kernel's implementation was "better", and didn't test more typically loads (e.g. a mixture of smaller sequential reads, some random reads and various writes) and therefore didn't find out that BSD was better under more realistic situations.

Mostly what I'm saying is that one benchmark with no real information about what was benchmarked or why there was a performance difference it's virtually meaningless.

Of course I'd also worry about bias - who did the benchmark? If BSD developers did the benchmark and said "OMG - thier exo-kernel is faster than our monolithic kernel" then I'd be a lot less sceptical. The number of bad ideas is several orders of magnitude greater than the number of good ideas, yet the number of research papers that say "We spent years researching this and found out that the idea is a bad idea" is far below the number any sane person would expect. Are researchers so lucky that they only ever choose ideas that end up being good ideas; or do they choose something they think might be a good idea and then make the results match their initial expectations?


Cheers,

Brendan

[Combuster]

"We spent years researching this and found out that the idea is a bad idea" is far below the number any sane person would expect.

No result is also a result, but that won't get you published into a scientific paper. So people are likely to keep going until they do have a result - preferably a positive one.

[Rusky]

Could those same optimisations be done on BSD, and if they were would BSD have been faster than the exo-kernel (was the performance difference due to having an exo-kernel, or were they caused by implementation differences that have nothing to do with exo-kernels)?

The optimizations were enabled by the exokernel design: http://pdos.csail.mit.edu/papers/exo-so ... 0000000000

Mostly what I'm saying is that one benchmark with no real information about what was benchmarked or why there was a performance difference it's virtually meaningless.

Of course I'd also worry about bias - who did the benchmark? If BSD developers did the benchmark and said "OMG - thier exo-kernel is faster than our monolithic kernel" then I'd be a lot less sceptical. The number of bad ideas is several orders of magnitude greater than the number of good ideas, yet the number of research papers that say "We spent years researching this and found out that the idea is a bad idea" is far below the number any sane person would expect. Are researchers so lucky that they only ever choose ideas that end up being good ideas; or do they choose something they think might be a good idea and then make the results match their initial expectations?

This is always something to watch out for, although as Combuster pointed out the number of research papers with negative results isn't really an indicator of anything. In my experience, however, the exokernel researchers have been much less biased, much more conservative in their benchmarks, and much more thorough in what they investigate, than, say, microkernel researchers. The paper I linked above is a good example, and here are some more: http://pdos.csail.mit.edu/PDOS-papers.html#Exokernels

[Brendan]

Hi,

Could those same optimisations be done on BSD, and if they were would BSD have been faster than the exo-kernel (was the performance difference due to having an exo-kernel, or were they caused by implementation differences that have nothing to do with exo-kernels)?

The optimizations were enabled by the exokernel design: http://pdos.csail.mit.edu/papers/exo-so ... 0000000000

No, that says "most programs on the emulator run only a few percent slower than the same programs running directly under Xok/ExOS.". Then it goes on to say that some things are faster because checks can be avoided (and CPL=3 -> CPL=0 -> CPL=3 switches are sometimes avoided); but (in a relatively biased way), neglects to mention that some things are slower because extra checks (and extra CPL=3 -> CPL=0 -> CPL=3 switches) are needed - e.g. when the libOS has to call the exo-kernel multiple times for one emulated system call.


Cheers,

Brendan

[Rusky]

Oops, missed that. I must have misread it or mistaken it for something else. That's still a very good paper though.

How is that biased? It's talking specifically about the parts that are faster. I would guess that anyone reading this paper (except me obviously) would get that and infer why.

[Rusky]

It may not have been binary emulation I was thinking of. Here is another section of that paper that more closely resembles what I was remembering: http://pdos.csail.mit.edu/papers/exo-so ... 0000000000 (scroll down for a pretty graph)

Unmodified (but recompiled) applications used in compiling a typical software package performed almost exclusively better on an exokernel than even on an OpenBSD using the optimizations available because of the user-space file system implementation.

So both the user-space file system implementation and the exokernel increased performance. The user-space file system was portable to OpenBSD, but that wasn't the only reason the exokernel was faster.

Later on in the paper, the exokernel is about the same speed as FreeBSD on a different, more CPU-intensive benchmark emphasizing fork() rather than IO. However, it still beats OpenBSD, and the authors blame the exokernel's performance on its relatively un-optimized implementation of fork().

There are several other places where exokernels win performance-wise on (in my opinion) well-chosen and applicable benchmarks, and this is all ignoring the potential for insane performance increases due to overriding libOS abstractions.

[Brendan]

Hi,

It may not have been binary emulation I was thinking of. Here is another section of that paper that more closely resembles what I was remembering: http://pdos.csail.mit.edu/papers/exo-so ... 0000000000 (scroll down for a pretty graph)

Unmodified (but recompiled) applications used in compiling a typical software package performed almost exclusively better on an exokernel than even on an OpenBSD using the optimizations available because of the user-space file system implementation.

Imagine a triangle. Label the point at the top of the triangle "performance", the point on the left "stability" and the point on the right "features". The triangle represents the compromises that have to be made between these opposing goals. Now place a dot in that triangle to represent the best theoretically possible monolithic kernel for stability. Now do another dot to represent the best theoretically possible monolithic kernel for features. Now randomly place one more dot to represent an arbitrary exo-kernel. Finally, try to explain how measuring performance alone (and ignoring stability and features) has any meaning whatsoever in a comparison between any kernel/s of any type/s.

Now look at the date in the copyright at the bottom of the paper you've linked to (it's 1995). If you look at the history of FreeBSD you'll notice that FreeBSD would have to have been less than 2 years old when the paper was written. How much do you think FreeBSD would have improved since then? Does it qualify as "the best monolithic kernel theoretically possible"? How much could've Xok/ExOS improved? Does Xok/ExOS qualify as "the best exo-kernel theoretically possible"?

To fairly test if exo-kernel is better/worse than monolithic, you'd need to compare many attributes (e.g. performance, stability, features) for the best theoretically possible exo-kernel and the best theoretically possible monolithic kernel. Have the researchers done this?

Now get 2 blind people, spin them until they've very dizzy, give them 3 darts each, tell them you've placed a dart board somewhere in the room (not necessarily on a wall) and get them to try to hit the bullseye. When they both miss the unknown target by a massive margin, use these results to conclusively prove that apples taste better than oranges.


Cheers,

Brendan

[Rusky]

I'm perfectly aware of the tradeoffs. I was answering a question about performance with details about performance. Do however note a few things:

The exokernel benchmarks erred excessively on the side of caution, so I would put it in a more-stable part of the triangle.

FreeBSD was in fact forked from 386BSD, which is a year older, and the exokernel was also benchmarked against OpenBSD, which had similar roots. 386BSD has an even older background.

On the other hand, the exokernel was a research kernel, with far less time to mature.

Disregard the benchmarks if you like, but they still prove something, if not the ultimate supremacy of exokernels (which obviously nobody is claiming).

[Brendan]

Hi,

There is an alternative way of looking at it - not from benchmarks, but theoretical differences.

If you've got a functionally identical monolithic kernel and exo-kernel (e.g. same code wherever possible, with same features, stability, etc); what differences would you have?

The first difference would be where the "CPL=0 -> CPL=3 -> CPL=0" transitions are. I'd expect that an exo-kernel would have more of these transitions; but frankly I doubt the different would be very significant.

The next difference would be global optimisations. Things like trying to intelligently prefetch data from disk (and swapping, etc), and scheduling and power management. When important pieces are duplicated in isolated processes, maintaining the global state needed to do these optimisations efficiently would become a nightmare, and I'd expect exo-kernels to suck badly because of this.

The next difference would be private optimisations (e.g. applications that use their own customised libOS to improve performance). This is mostly the land of pipe dreams. Application developers couldn't be bothered and (if they did bother) the number of potential optimisations they could do (that can't also be supported by a monolithic kernel) is almost zero.

The final difference is security. If a malicious application can use it's own private libOS, then all hell breaks loose. For example, you can't expect the potentially malicious file system code (in the library) to keep the file system in tact, and can't even assume that the application's libOS respects file permissions.


Cheers,

Brendan

[Colonel Kernel]

Imagine a triangle. Label the point at the top of the triangle "performance", the point on the left "stability" and the point on the right "features". The triangle represents the compromises that have to be made between these opposing goals. Now place a dot in that triangle to represent the best theoretically possible monolithic kernel for stability. Now do another dot to represent the best theoretically possible monolithic kernel for features. Now randomly place one more dot to represent an arbitrary exo-kernel. Finally, try to explain how measuring performance alone (and ignoring stability and features) has any meaning whatsoever in a comparison between any kernel/s of any type/s.

I think you're fundamentally misunderstanding the goal of research. Research is all about experimentation, and a good experiment focuses on one variable while controlling for all the others. Trying to decide which OS architecture is best for a given purpose is "an exercise for the reader".

[Rusky]

The next difference would be global optimisations. Things like trying to intelligently prefetch data from disk (and swapping, etc), and scheduling and power management. When important pieces are duplicated in isolated processes, maintaining the global state needed to do these optimisations efficiently would become a nightmare, and I'd expect exo-kernels to suck badly because of this.

It turns out that optimizing individual applications improves global performance (see the Xok paper). The exokernel can still handle things like tracking LRU, page/block mappings, etc. It just does it at a lower level that gives applications more opportunities to utilize resources effectively.

The next difference would be private optimisations (e.g. applications that use their own customised libOS to improve performance). This is mostly the land of pipe dreams. Application developers couldn't be bothered and (if they did bother) the number of potential optimisations they could do (that can't also be supported by a monolithic kernel) is almost zero.

Application developers don't have to do it themselves. Exokernels just enable a much wider range of potential libOSes to choose from, that can all run on one system at once. So big-scale applications like web servers and databases, office suites, web browsers, etc. can choose interfaces that are more optimal. Do you really think someone like Apache or MySQL or Mozilla would just "not bother"?

The final difference is security. If a malicious application can use it's own private libOS, then all hell breaks loose. For example, you can't expect the potentially malicious file system code (in the library) to keep the file system in tact, and can't even assume that the application's libOS respects file permissions.

You miss the whole point of exokernels. They manage permissions at the hardware level, so the malicious file system code in the library HAS to respect permissions. The file system is particularly tricky to get right like this, but they have done it (described in the Xok paper).