OS: how does kernel virtual memory help in making swap pages of the page table easier?

Question

Upon reading this chapter from "Operating Systems: Three Easy Pieces" book, I'm confused of this excerpt:

If in contrast the kernel were located entirely in physical memory, it would be quite hard to do things like swap pages of the page table to disk;

I've been trying to make sense of it for days but still can't get as to how kernel virtual memory helps in making swap pages of the page table easier. Wouldn't it be the same if the kernel would live completely in physical memory as the pages of different page tables' processes would end up in physical memory in the end anyway (and thus be swapped to disk if needed)? How is it different when page tables reside in kernel virtual memory vs. in kernel-owned physical memory?

Answer 1

The point may not be the swapping mechanism.

In a page-based operating system, if there is some execution that is not in the page-based address space, then the existence of that execution needs to be accommodated by all the mechanisms that are page-based and possibly related to that execution, such as the important mechanism in paging: swapping

If you're still confused as to why swapping is more difficult, imagine that you have a chunk of physical memory that isn't paged and may be accessed by all processes. For example, when the chunk has growed, and owns a large space of memory, then the menory is less used and should be swapped out. But the chunk of memory is not paged, how could it be swapped? That leads to a disorder.

Answer 2

Let's assume the kernel needs to access a string of characters from user-space (e.g. maybe a file name passed to an open() system call).

With the kernel in virtual memory; the kernel would have to check that the virtual address of the string is sane (e.g. not an address for kernel's own data) and also guard against a different thread in user-space modifying the data the pointer points to (so that the string can't change while the kernel is using it, possibly after the kernel checked that the string itself is valid but before the kernel uses the string). In theory (and likely in practice) this could all be hidden by a "check virtual address range" function. Apart from those things; kernel can just use the string like normal. If the data is in swap space, then kernel can just let its own page fault handler fetch the data when kernel attempts to access it the data and not worry about it.

With kernel in physical memory; the kernel would still have to do those things (check the virtual address is sane, guard against another thread modifying the data the pointer points to). In addition; it would have to convert the virtual address to a physical addresses itself, and ensure the data is actually in RAM itself. In theory this could still be hidden by a "check virtual address range" function that also converts the virtual address into physical address(es).

However, the "contiguous in virtual memory" data (the string) may not be contiguous in physical memory (e.g. first half of the string in one page with the second half of the string in a different page with a completely unrelated physical address). This means that kernel would have to deal with this problem too (e.g. for a string, even things like strlen() can't work), and it can't be hidden in a "check (and convert) virtual address range" function to make it easier for the rest of the kernel.

To deal with the "not contiguous in physical memory" problem there's mostly only 2 possibilities:

a) A set of "get char/short/int.. at offset N using this list of physical addresses" functions; or

b) Refuse to support it in the kernel; which mostly just shifts unwanted burden to user-space (e.g. the open() function in a C library copying the file name string to a new page if the original string crossed a page boundary before calling the kernel's open() system call).

Answer 3

In an ideal world (which is what we live in now with kernels that are hundreds of megabytes in size running on machines with gigabytes of physical RAM) the kernel would never swap even parts of itself. But in the old days, when physical memory was a constraint, the less of the kernel in physical memory, the more the application could be in physical memory. The more the application is in physical memory, the fewer page faults in user space.

THe linux kernel has been worked over fairly extensively to keep it compact. Case in point: kernel modules. You can load a module using insmod or modprobe, and that module will become resident, but if nothing uses is, after a while it will get swapped out, and that's no big deal because nothing is using it.