OSDev.org

abhoriel wrote:There's a lot of talk about microkernels being unsuitable for creating POSIX based operating systems. This is due to the fact that the POSIX API (and POSIX programs) in general rely on synchronous system calls, such that in many cases each system call forces at least two context switches (eg. app -> VFS -> app)

Is it therefore possible to create a useful microkernel-based general purpose operating system using the POSIX API? What about QNX? Do newer features (at least on x86...) such as TLB tagging help mitigate the context switch overhead?

abhoriel wrote:Could a microkernel architecture potentially scale better (on increasingly SMP systems) by reducing TLB shootdowns? Surely any changes to a monolithic kernel's memory mapping (eg. from adjusting the kernel heap size) must cause a TLB shutdown on all cores, as the monolithic kernel's memory is mapped into every application's address space. If (as in a microkernel) the operating system is divided up into several separate address spaces, TLB shootdown should be much less problematic, as eg. if the ext2 driver wants to allocates memory on the heap causing a change to its page tables, shootdown will only need to occur on the cores which are currently using the ext2 driver's address space. Are there other instances in which the microkernel architecture could be nicely scalable?

Boris wrote:Posix does have async IO methods.

Kevin wrote:Don't forget that while having AIO for everything is very nice in theory, in practice using it is a PITA and even just because of the complexity most people will avoid it if there is no really compelling reason to use it.

Kevin wrote:The other point is that in many cases there is no reason at all.

Kevin wrote:If you're going to read the directory contents and then print it to stdout, you just have to read the data before you can output it. There is no parallelism in there, even with AIO you'd send the read and then wait for it to complete without doing anything else in parallel.

Kevin wrote:(In theory you could split reading the directory into multiple requests and then do the output in parallel, but unless you have huge directories, that will make the requests too small and hurt performance rather than helping it.) I would guess that most I/O is actually of this type where even with an AIO interface you would wait for completion and effectively do synchronous I/O.

Sik wrote:I'd imagine that parsing file formats is where it gets at its worst though. Most of the time you simply can't move forward until you've parsed the previous chunk of data, which requires waiting for it to arrive. That's not even a case of code being designed as synchronious, it's a case of the data being so. Even those formats designed to let you hoop around still require you to read the structures first. And of course when writing the files you need to write everything in sequence, you can't pass the data in a random order. Food for thought.

Sik wrote:That said, wouldn't an entirely asynchronous be purely event driven, with no concept of main loop at all? (possibly with multiple events being fired literally simultaneously into their own threads)

    for(ever) {
        getMessage();
        switch(message.type) {
            case A:
                handleA();
                break;
            case B:
                handleB();
                break;
        }
    }

Brendan wrote:For "everything asynchronous", most of the time you end up a kind of finite state machine (with "switch(message.type)" in a loop), and once you get used to it it's not harder at all. The problem is that you do need to get used to it first.

For this trivial example; there is parallelism - you can process one piece and output it while you're waiting for the next piece to arrive (without the inconvenience of setting up a "worker thread"). More importantly, for "everything asynchronous" it's easier to do it this way than it is to do it the slower way.

For POSIX where "asynchronous" is too painful for anyone to bother, most IO ends up being synchronous. For "everything asynchronous" where "synchronous" is too painful for anyone to bother, most IO ends up being asynchronous.

Kevin wrote:

Brendan wrote:For "everything asynchronous", most of the time you end up a kind of finite state machine (with "switch(message.type)" in a loop), and once you get used to it it's not harder at all. The problem is that you do need to get used to it first.

Yes, it is harder and results in less readable code. It's the difference between structured programming and gotos all over the place. And then you have some boilerplate code for stater transitions between each asynchronous operation, you don't keep your stack contents across async ops, etc.

Kevin wrote:Such event loops are great if your program is doing rather trivial things. It stops being fun when your code becomes a little more complex.

Kevin wrote:

For this trivial example; there is parallelism - you can process one piece and output it while you're waiting for the next piece to arrive (without the inconvenience of setting up a "worker thread"). More importantly, for "everything asynchronous" it's easier to do it this way than it is to do it the slower way.

My point (which you ignored by tactical quote splitting) was that with common directory sizes, you would always send one request and get one response, and splitting them into smaller pieces in order to allow things to actually run in parallel would hurt performance rather than improving it.

Kevin wrote:In other words, while there may be some programs for which this actually matters, using AIO would be premature optimisation for at least 95% of the cases where the directory entries are read and would come with costs, but no benefits.

Kevin wrote:

For POSIX where "asynchronous" is too painful for anyone to bother, most IO ends up being synchronous. For "everything asynchronous" where "synchronous" is too painful for anyone to bother, most IO ends up being asynchronous.

Please show me your API that makes emulating synchronous requests hard while making async requests easy. Unless you're rather inventive with artificial restrictions in the programming language, this seems rather unlikely to happen.

Brendan wrote:It's more readable because you're only focusing on one "event" at a time, biolerplate code exists regardless, the stack contents are irrelevant ("state" becomes part of the the finite state machine).

You're saying that a deliberately trivial example was trivial while failing to extrapolate to anything that isn't.
[...]
And now the deliberately trivial example that you've failed to extrapolate from has become 95% of all cases. Awesome.

For mine; you can receive a message from any sender at any time. You send a "open file request", you might get a "user pressed the cursor key" message, then a "kernel is running low on memory" message, then a "process you started has terminated" message, then 1234 more unrelated messages, then the "open file reply". There is no guaranteed order (e.g. X sends a message to Y and Z at the same time; when Y receives the message from X it sends a message to Z; Z can receive the later message from Y before it receives the earlier message from Z). There is also no guaranteed delivery (successfully sent does not imply it will be successfully received).

• Much like what Brendan wants, everything is asynchronous (modulo some irrelevant edge cases), and the programming model prevents simulated synchronous I/O - your code always runs in the context of a pre-existing event loop, with no way to get a new event other than returning and getting re-called.
• Plain callbacks made this hellish (unbounded nesting of functions) so they switched to a promise-based API, to remove the nesting:

  Code: Select all

  do_IO_1().then(function (result1) {
      return do_IO_2(result1);
  }).then(function (result2) {
      return do_IO_3(result2);
  }).then (function (result3) { ... });

• Promises with .then(callback) methods still prevent you from using the language's control structures, so now they're adding async/await to Javascript:

  Code: Select all

  let result1 = await do_IO_1();
  let result2 = await do_IO_2(result1);
  let result3 = await do_IO_3(result2);

Rusky wrote:So we have some empirical evidence that even in situations where people can't fall back on synchronous IO or simulate it, they still won't just "get used to it," because it is an objectively less-clear way to write a program (I'm not saying nobody will do it- for example, Nginx is written this way because C leaves no way around it). Writing event loops manually is the async equivalent of writing a program exclusively with goto statements.

Kevin wrote:

Brendan wrote:It's more readable because you're only focusing on one "event" at a time, biolerplate code exists regardless, the stack contents are irrelevant ("state" becomes part of the the finite state machine).

It's less readable because in an "everything aynchronous" model a single event contains almost no code, so focussing on it doesn't give you a lot of information. What's missing is the big picture, the connection between the states. It's all there, but it's less visible.

Kevin wrote:

You're saying that a deliberately trivial example was trivial while failing to extrapolate to anything that isn't.
[...]
And now the deliberately trivial example that you've failed to extrapolate from has become 95% of all cases. Awesome.

Maybe what I'm saying is that a huge part of real-world applications are what you would call trivial.

Kevin wrote:

For mine; you can receive a message from any sender at any time. You send a "open file request", you might get a "user pressed the cursor key" message, then a "kernel is running low on memory" message, then a "process you started has terminated" message, then 1234 more unrelated messages, then the "open file reply". There is no guaranteed order (e.g. X sends a message to Y and Z at the same time; when Y receives the message from X it sends a message to Z; Z can receive the later message from Y before it receives the earlier message from Z). There is also no guaranteed delivery (successfully sent does not imply it will be successfully received).

Great. Now how is waiting for AIO completion before you do something else (i.e. emulating synchronous operations) so hard in this model that nobody would bother doing that? It seems fairly trivial to me.

Rusky wrote:Async event loops are a pain because the logical flow of a single conceptual process is split up across a bunch of switch cases.

Rusky wrote:So we have some empirical evidence that even in situations where people can't fall back on synchronous IO or simulate it, they still won't just "get used to it," because it is an objectively less-clear way to write a program (I'm not saying nobody will do it- for example, Nginx is written this way because C leaves no way around it).