1

In the book Operating System Concepts,

In the summary it states:

A monolithic operating system has no structure; all functionality is provided in a single, static binary file that runs in a single address space. Although such systems are difficult to modify, their primary benefit is efficiency.

A layered operating system is divided into a number of discrete layers, where the bottom layer is the hardware interface and the highest layer is the user interface. Although layered software systems have had some success, this approach is generally not ideal for designing operating systems due to performance problems.

Is the reason why the layered operating system approach is slow is because a monolithic operating system is just a single process running on the computer. But the layered operating system instead has multiple processes running on the system and there's overhead when multiple processes are communicating to each other via message passing?

Greg Burghardt
  • 37,083
Eric Gumba
  • 279
  • Simply imagine the difference in effort between deciding to go catch a movie, and co-ordinating a group of 15 to attend a movie together, and you're not far off the overhead that message-passing between layers involves. – Kilian Foth Sep 29 '22 at 08:12
  • 2
    That book seems to use “monolithic” in a somewhat unusual meaning. Monolithic software still has internal structure, such as layers. In an OS context, we're mostly looking at the kernel. Monolithic kernels are a thing, for example Linux. Linux is well-structured into different modules and layers, but runs in a single address space. The opposite is not a layered OS, but a microkernel where more tasks run as userspace services. While good for security, this implies more message-passing overhead. – amon Sep 29 '22 at 09:20
  • 1
    Honestly, the whole question is overgeneralizing. It's premise is that an OS has something like a speed - this is nonsense. Any modern OS has a lot of of services, and those services have different speed. Some of them may be compared to corresponding services of other OSes - and on that basis, the question may start to make sense. However, the answer will still depend on the specific implementation of a layered OS, and the specific layers. .... – Doc Brown Sep 29 '22 at 09:41
  • ... So it might make sense to ask, for example, if interprocess communication (which is one OS service among many) might be faster on OS "foo" than on OS "bar" on the same hardware platform because OS bar has a certain kind of layering and OS "foo" has not. But currently, the question is only an invitation for making wild speculative guesses. – Doc Brown Sep 29 '22 at 09:42
  • Abstraction makes things slower. (Some abstractions make things slower than others) – user253751 Sep 29 '22 at 16:24

3 Answers3

3

First my personal bias: I favor micro-kernels and and a some abstractions. Like in Minix-3.

The monolithic OS must take care of security issues like kernel-space and user-space. It can be somewhat less systematically coded. In general you get less software quality. Linux is a good example where the quality finally is quite mature, but with needless framework library alternatives. Windows has a history of obsolete frameworks, but - as far one can judge - is at least on the GUI front refreshing.

The layered OS keeps things tight, defines algebraically complete APIs. The number of layers is not overdone normally. However passing data between layers is not done by simple function call passing all the data, but more by message passing. The sharing of memory is more orchestrated. But such a separation between layers makes sense: you do not want a simple compiled user application to play with the file system on a monolithic system too.

In general layers only deliver overhead when doing much work on the transport between the layers, like message passing or keeping mirror data on both sides of the layer.

A monolithic OS has its weak spots too, also in speed and efficiency. Sharing a directory on a SMB drive and some other network drive may not be done on a systematic recombinable API, where authentication and such is a general module. A monolithic OS has less orchestration for instance for a boot.

A layered micro-kernel based Minix-3 can detect hanged applications/services and even recover from them, before the user notices.

But you are right, message passing makes things slower. But the overhead should not need to be that dramatic. Write you write byte-by-byte to a file over layers, one may expect a large cost. However there was (still is?) a Java OS, that to some extent dealt with that. Maybe a future language à la Rust may solve that problem. To clarify what I mean: in OOP language Smalltalk everything was a message, and Smalltalk was a persistent world. If the low-level machine implementation were good, that could speed up things. No one is complaining on virtual methods too.

One other point: the development of a monolithic OS takes longer and is more painful IMHO. One may hack API together fast, but then one needs unravel things when implementing some feature everywhere like security or caching.

Joop Eggen
  • 2,051
  • 12
  • 10
  • "The layered OS keeps things tight, defines algebraically complete APIs." Correct me if I'm wrong, but nothing stops you from designing a modular monolithic kernel with well designed APIs between the modules. It's just that the modules can cohabitate in the same API. i.e. the APIs between them are direct C (or other lang) interfaces from within the same address space, rather than some IPC mechanism. – Alexander Sep 29 '22 at 16:38
  • 1
    @Alexander for a language like modular java I would entirely agree. But there comes in every software the point where different "business objects" (modules) are combined to form something practical. Those are the areas to be careful. And other's code might not be as carefully written as your own code. I just wanted to say a layered OS can be more solid. However the mechanisms should be as simple as the function calls of a monolithic OS. There I agree. We could compare an OS with a large software system (CORBA,, and others). – Joop Eggen Sep 29 '22 at 16:59
1

Mind that "layering" is just an idea, an abstraction in people's heads that not necessarily has any relation with technical implementations.

If I were to fill up my tank I could say I play several roles to get this done: owner to give the order, chauffeur to get the car to the pump, assistant to fill the tank, financier to pay for the fuel and chauffeur again to get the car back to the house. It could all be me or I could take my wife to make the payment and the neighbor's kid to work the pump. The same model could be applied to different implementations.

Likewise you can have an OS that is built into a single module, is split up into different modules, runs in a single process, runs in different processes, utilizes processor support for separating code or not, is call-based or message-based, uses whatever combination of technical varieties for an implementation. None of this prevents you from speaking about (functional) layers.

In software a layer is not made of brick and mortar. It can be any separation of concerns and the jump from one layer to the next could be as thin as a procedure call within a single thread or as thick as a document being passed over a WAN. The layers are just a means to talk about the system, to convey a way of looking at it.

It is my perception that the monolith vs micro kernel debate is heavily politicized. People bringing this up typically just want to say that <some alternative system> is better than Microsoft Windows.

Fun fact: Windows NT originally used 80386 processor support to separate the different layers in the OS, particularly the (video) hardware from the higher layers. It turned out to be unusable (so slow) so they dropped the ring separation on the processor level and it performed a lot better. Same layers, just technically less rigidly separated.

Martin Maat
  • 18,435
0

All abstractions make things slower (but some are worse than others).

A program that is written with no abstractions will directly tell the computer what it needs to do to complete a task. If written well, therefore, the computer can use as few steps as possible.

Adding an abstraction constrains the ways the program can be written. For example, we might say this code is the disk process, that code is the filesystem process, and the disk process only talks to the filesystem process through a specific API. Then, the most efficient way to write the program might not be available any more. For example the filesystem process might need to store some data related to certain disk blocks; so might the disk process; if they are separated then they need to be stored in two separate data structures and the computer needs to look up the disk block in each, instead of looking it up in one structure and having access to both sets of data.

In some cases it may be possible to create an abstraction which doesn't cause the program to run any slower, but in general that is not possible.

A layered operating system has more abstractions - more division into different parts and rules about how the parts can talk to each other - so it is necessarily slower. This is true for all software - by the way - not just operating systems.

This doesn't mean abstractions are bad - there are usually advantages which sometimes outweigh the extra slowness.

user253751
  • 4,873
  • .. and often abstraction unburdens the programmers of a system from a lot of debugging and fixing issues, so they have more time to optimize slow parts of the system. So in reality, things are not so simple as in theory. – Doc Brown Sep 30 '22 at 12:27
  • Also, some abstractions exist only in the sources, as they can be compiled away, giving you the best of all worlds. – Deduplicator Oct 01 '22 at 10:13
  • @Deduplicator They are the extreme minority. Even C++'s unique_ptr apparently has overhead because it changes the calling convention to the one used for objects instead of the one used for values. – user253751 Oct 01 '22 at 19:09
  • @user253751 clang introduced the attribute trivial_abi for that. Also, abstraction is so ubiquitous, I doubt you really see most of the abstractions, most of them truly free. Anyway, I invoke the mystical much-sought sufficiently-advanced compiler for this. – Deduplicator Oct 01 '22 at 19:28