By: Adrian (a.delete@this.acm.org), July 18, 2022 11:02 pm
Room: Moderated Discussions
Brendan (btrotter.delete@this.gmail.com) on July 18, 2022 3:11 pm wrote:
>
> Page tables/MMU allow some powerful tricks (swap space, copy on write/allocate on demand, etc); and
> a kernel can and should exploit these same powerful tricks for its own benefit (e.g. making data that
> kernel shouldn't need to access unable to be accessed accidentally to improve kernel bug and/or vulnerability
> detection, allowing parts of itself (and user-space page tables) to be sent to swap space to reduce
> kernel's memory consumption, using a deliberately randomized physical address for each individual
> page to improve kernel's security, NUMA optimizations where different copies of read-only kernel code
> and data are used by different CPUs to improve kernel's performance, etc).
>
> In this case, if there are no page faults in privileged mode, then kernel
> must be a steaming pile of garbage (unable to benefit from MMU).
>
The usefulness of those tricks inside a kernel is controversial and I happen to be among those who believe that the kind of code that can benefit from such tricks should not belong to the kernel.
Also, my definition of a kernel which is a steaming pile of garbage is very different. For example, a kernel where a buggy device driver can make the computer unresponsive, or where it is not possible to kill a process at any time, is much closer to being a steaming pile of garbage than any kernel that is unable to benefit from MMU.
The difference between the 2 definitions is that the quality of a kernel must be judged based on user-visible behavior. Whether benefiting from the MMU is an advantage for a kernel must be proven based on some observable quality of the kernel.
I agree that inside a very complex kernel, e.g. Linux, which includes a huge number of device drivers, the use of the MMU can be unavoidable, in order to provide memory protection and to allow dynamic allocation of memory pages. However, I believe that most of those device drivers should not work in privileged mode, and then they could use the MMU like any user programs.
If on CPU architectures like x86-64, their performance would become lower in non-privileged mode, that just shows that the hardware is not designed well, with excessive overheads on context switching and IPC, not that the software architecture is good as it is.
>
> Page tables/MMU allow some powerful tricks (swap space, copy on write/allocate on demand, etc); and
> a kernel can and should exploit these same powerful tricks for its own benefit (e.g. making data that
> kernel shouldn't need to access unable to be accessed accidentally to improve kernel bug and/or vulnerability
> detection, allowing parts of itself (and user-space page tables) to be sent to swap space to reduce
> kernel's memory consumption, using a deliberately randomized physical address for each individual
> page to improve kernel's security, NUMA optimizations where different copies of read-only kernel code
> and data are used by different CPUs to improve kernel's performance, etc).
>
> In this case, if there are no page faults in privileged mode, then kernel
> must be a steaming pile of garbage (unable to benefit from MMU).
>
The usefulness of those tricks inside a kernel is controversial and I happen to be among those who believe that the kind of code that can benefit from such tricks should not belong to the kernel.
Also, my definition of a kernel which is a steaming pile of garbage is very different. For example, a kernel where a buggy device driver can make the computer unresponsive, or where it is not possible to kill a process at any time, is much closer to being a steaming pile of garbage than any kernel that is unable to benefit from MMU.
The difference between the 2 definitions is that the quality of a kernel must be judged based on user-visible behavior. Whether benefiting from the MMU is an advantage for a kernel must be proven based on some observable quality of the kernel.
I agree that inside a very complex kernel, e.g. Linux, which includes a huge number of device drivers, the use of the MMU can be unavoidable, in order to provide memory protection and to allow dynamic allocation of memory pages. However, I believe that most of those device drivers should not work in privileged mode, and then they could use the MMU like any user programs.
If on CPU architectures like x86-64, their performance would become lower in non-privileged mode, that just shows that the hardware is not designed well, with excessive overheads on context switching and IPC, not that the software architecture is good as it is.
