This is the 16th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

This series of reading notes for Systems Performance: Enterprise and the Cloud, 2nd Edition (2020) adds some personal understanding and expansions, as well as additional references for some of the more difficult areas

Kernel

In the classical model, the position of the kernel in the operating system structure is shown in the figure below:

From the inside out:

  • Hardware: Indicates the Hardware devices on which the operating system (OS) runs.
  • Kernel: The core software of an operating system. The Kernel manages CPU scheduling, memory, file systems, network protocols, and various system devices (disk IO, network IO, and so on). Services are provided through system calls.
  • System Calls: Provides a program interface to access hardware devices or kernel services. For example,open.close.read.write.ioctlAnd so on, need to include the header fileunistd.h.
  • System LibrariesIt may not be convenient to use system calls directly, but we can use wrapped library functions programmatically. As you can see from the diagram, there is a gap because applications can also use system calls without using system libraries. The Go runtime, for example, uses its own system call layer rather than the standard librarylibc.

Many current operating systems have made variations on this model, which we’ll examine in more detail later.

The kernel perform

Through constant iteration, the kernel is now huge, with millions of pieces of code. Kernel execution is on-demand, such as when a user-level application makes a system call, or when a device sends an interrupt. In addition, some kernel threads asynchronously perform maintenance tasks, which may include kernel clock programs and memory management tasks, but these tasks are kept as lightweight as possible and use very little CPU resources.

I/O intensive applications such as Web servers, which constantly receive requests and return responses, are often executed in a kernel context. Computationally intensive applications do not disturb the kernel as much as possible and can execute on the CPU without interruption. The kernel scheduler determines which thread will run, which will wait, and which CPU will be scheduled to. The kernel will choose a CPU that has a hotter hardware cache or is more local to the process to improve performance.

Kernel mode and user mode

Kernel mode: When running kernel programs, the CPU is in kernel mode. In this state, all device access and privileged command execution are allowed. The kernel controls access to the device to implement multi-process processing. Data between processes or users is not accessible to each other unless explicitly specified

User mode: The mode in which the CPU runs a user program. With a system call, it switches from user mode to kernel mode and executes with a higher permission level:

Switching from the user mode to the kernel mode is a mode switch. All system calls switch from the user mode to the kernel mode. Some system calls switch from the user mode to the kernel mode. Such switching has performance loss, which is generally avoided through the following optimizations:

  • User-mode syscalls: Some system calls can be implemented in the user-mode library. Linux implements this by exposing virtual Dynamic Shared Object (vDSO) at man7.org/linux/man-p…
  • Memory Mappings: Used to load Memory pages on demand (missing page interrupts), as described below. This avoids system calls from directly accessing IO.
  • Kernel bypass: enables user-mode programs to access devices directly, such as Data Plane Development Kit (DPDK)
  • Kernel-based applications: for example, the TUX server running on the kernel and Berkeley Packet Filter (BPF). One well-known set of tools for BPF implementation is github.com/iovisor/bcc