Russell Johnston

Speaking of BIOS, have you thought about what kind(s) of firmware the Mill would work with? Mainstream UEFI? Coreboot? Something else?

I like it!

Some questions about a few fixed-size things. Stacks will often need to be bigger than one segment/stacklet. There may also be more processes/threads than available turf/thread ids- Linux’s pid_t is 32 bits for example. How would these things be handled?

Stacklets could just be entry points that switch to the real stack I guess. How would that work, since call/return seems to be the only (user-available) way to mess with the stack pointer? This also goes with an earlier question I asked about continuations/coroutines.

If I understand correctly, a slightly higher-level, unscheduled version of Mill assembly is basically SSA, so if you don’t care about the details of op scheduling you could use e.g. LLVM IR.

I get the impression that memory for stack will run out before possible belt IDs, so that combined with the spiller running asynchronously is what leads to “no constraint on the spiller or core speed other than spiller bandwidth.”

I should’ve been more clear- exokernels expose the driver directly (or even a very thin layer on top), not the device hardware itself. That way they can control access more granularly (e.g. disk blocks rather than whole disks). MIT’s exokernels had all their drivers in a monolithic kernel; they removed things like file systems and the network stack into libraries, with the kernel interface designed to allow securely cooperating implementations.

The premise is to allow different applications to all run at once even when doing crazy lower-level optimizations. One of their big motivating examples is a web server (closer to a proxy cache today- it just serves static files) that allocates particular disk blocks to put files from individual pages closer together, TCP packet merging because of their knowledge of how the response is laid out, etc. It ended up being 8x faster than Harvest (which became squid) and 4x faster than their port of Harvest to the exokernel.

Another example I liked because it was particularly simple and clean was a ‘cp’ implementation. It finds all the disk blocks in all the files it’s copying and issues big, sorted, asynchronous reads (the disk driver merges this with all other schedules, including other cp’s, etc). Then, while that’s going on, it creates all the new files and allocates blocks for them. Finally, it issues big asynchronous writes straight out of the disk block cache. This ended up being 3x faster than their cp using a unix libOS.

Neither of these (or any of their other examples) require any extra permissions- the libraries don’t even have to be in services because if they break it just takes down the application using it, instead of corrupting the disk or something. The exokernel already took care of only granting permissions to disk blocks that the application would access anyway.

There are still a more recent few exokernel projects floating around, but MIT has moved on. It probably didn’t catch on because some of its systems are either too complex to be worth the effort (file systems required downloading small bits of code into the kernel to verify things about metadata generically) or didn’t solve all the problems they had (packet filters still have some ambiguities that aren’t easy to resolve well for everyone).

However, many of their ideas have made their way into existing systems- Linux DRI is a very exokernel-like interface to the video card. Many ideas could still work out if you were willing to break compatibility as well- for example, a new exokernel could pragmatically decide to understand file system structures, while still letting the applications do most of the legwork themselves (and thus in the way best suited to their domain).

Exokernels are actually pretty different from microkernels (although the difference is somewhat orthogonal, rather than mutually exclusive).

Microkernels implement things like drivers and file systems in servers, essentially taking a piece of a monolithic kernel and moving it into a process. Applications still need to go through this interface to get things done without violating protection, so applications still can’t e.g. change around file system disk block allocation algorithms, or make their own decisions regarding swapping.

Exokernels, on the other hand, provide protection at a lower level- applications can access things like disk blocks directly rather than through a privileged server. This is typically done through libraries which run with exactly the same privileges as the application itself, but which can be bypassed for greater flexibility. For example, database indexes are sometimes faster to regenerate than to swap in from disk, so a database application could choose to discard indices rather than having its LRU page swapped out.

This is why exokernel research tends to show performance improvements over monolithic kernels, and microkernels research tends to be about minimizing performance losses compared to monolithic kernels. 😛

As I mentioned, you could easily have a microkernel whose servers expose their interfaces at the exokernel level rather than at the monolithic level. This would work really well on the Mill, where separating what would ordinarily be pieces of a kernel into services has a much lower cost.

• This reply was modified 10 years, 7 months ago by  Russell Johnston.

Ah, I like the hardware support for segmented stacks.

On thread/turf ids, how would the swapping out be handled with e.g. currently running threads needing their id revoked (as an analogy to swapping out an LRU page)? I’m asking out of pure “640k should be enough for anyone”-curiosity. 😛