Skip to content

L4

Context

It was very hard to make changes to the operating systems. You either support dynamic code loading or recompile and reboot the operating system. Therefore, we want to push the operating system code a little bit further up (as in closer to user-level), so that you don't need as much privilege and can run multiple different versions at a time.

Micro-Kernel Design 1
// TODO: Insert Diagram

Micro-Kernel Design 2
// TODO: Insert Diagram

Micro-Kernel Design 3
// TODO: Insert Diagram

Goal

  • For micro-kernel performance, is the low performance fundamental or it ties to specific implementations
  • Explore if colocation neccessary
  • Demonstrate specialization → existing features

Example

Existing kernels offer very generalized pipes that have significant overheads. However, not a lot of user programs are exploiting this generalization. Therefore, we can specialize these features to reduce these unneccessry overheads

  • Demonstrate extendability → new features

Example

Existing kernels do not have cache partitioning. We can show that this feature could be added very easily with micro kernel

Implementation

// Add L4 kernel diagram

L4 Micro Kernel Abstraction

  • Thread
  • Address Space
  • IPC (messages)

How do some key features of operating system work under this architecture (implementation)

Since Linux was built to run on multiple different hardware architectures, it has codes written in a hardware independent manner. Linux has a thin layer of abstraction that can port to different architecture interfaces. Therefore, the authors of L4 simply take L4 as a new CPU architecture and modify this interface to let Linux port to L4 without having to change Linux implementations.

There are some small changes that need to be made within Linux

Shadow paging:
Since L4 has the address space abstraction, L4 is responsible for managing the virtual address space. Therefore, it has to keep, maintain, and update page tables for every single process. Whenever we do a context switch, L4 has to switch the current page tables to the page tables that we are context switching to. Linux at the same time, thinks that it manages virtual addresses for all processes. Therefore, it also has page tables created for every single process. However, we will not install these page tables to the hardware because only L4 is trusted to manage memory address space. (These page tables are not installed to MMU). In short words, Linux will make change to its page tables and send this information to L4. L4 will verify that this is a valid action and update MMU correspondingly. → we have two copies of page tables.

  • Syscall
    The user application invokes syscalls not by sending a message directly to the Linux App, but having messages delivered by the L4 micro kernel, and vise versa for responses from the Linux App. Therefore, there are going to be some overheads.

Example: A user level process wants to call the read syscall

The user level process will send a "message" to L4 micro kernel and L4 will deliver this message to the Linux server, which is running as another user level application in the user level space.

User App → L4 → Linux App

After Linux receive this "message", it has implented read syscall. Therefore, corresponding actions are done, and the "response" is being delivered in the reserve direction.

User App ← L4 ← Linux App

In the higher level, it seems like User App is sending "message" to Linux App, but under the hood, the message must be delivered through the L4 micro kernel.

  • Page Fault

Example: A user level process does a memory reference that is going to result a page fault

On page fault, the hardware (MMU/TLB) is going to tranfer the control to L4 because L4 is the one that runs in privilege mode. However, L4 is not a fully function operating system. Therefore, L4 package up this page fault message, and send it to the Linux App running in the user space.

The Linux App will allocate a physical page and update the page table entry, and respond back to L4, and L4 will then send a message to the User App.

Takeaway

  • Perofmance difference between a L4 micro kernel implementation and a monolithic operating system is only 6-8% → we do not need co-locate.

  • When we come to specialization, L4 micro kernel can run faster than monolithic operating system.

  • It is an impressive operating system

When Linux in the user level handles syscalls, does it have to go L4 to access user application's address space?

No, because Linux is managing the page table for every single user process. It knows which physical page matches to the virtual page. Linux is modified by L4 authors in the way that it can just go to the physical memory and edit the physical pages.

My Questions

Question

Is it that running the operating system at privilege level faster or it is faster for apps to talk to os at privilege level

How can OS running at the user level does anything that its code implemented for running in privilege mode.

Back to top