2

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?

Mathieu
  • 8,840
  • 7
  • 32
  • 45
Glenn Mohammad
  • 3,871
  • 4
  • 36
  • 45

3 Answers3

1

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).

Brendan
  • 35,656
  • 2
  • 39
  • 66
  • is my understanding correct? Every time user program tries to access some memory location (e.g. heap), it uses a virtual address. At the time of system call when kernel takes controls, it sees a virtual address. Because kernel code (e.g. the code which is supposed to handle memory reference) exists in the same address space as user program, it can naturally understand the virtual address w/o switching page tables, flushing TLBs etc. This is one of benefits to map kernel code/data structure into every user process – torez233 Jul 17 '22 at 00:32
  • I'm also trying to rephrase your answer in my own language to test if I understand it correctly: The virtual address provides an illustration that data being references is laid out contiguously in the memory, which in reality the same data may or may not lay out contiguously in actual physical memory. The illustration makes programming easier. If kernel code exists entirely in physical memory, it cannot understand the virtual address and has to translate it into physical address, which exposes the “bad” reality that is harder to deal with – torez233 Jul 17 '22 at 00:38
  • 1
    @torez233: I think you've got it right :-) – Brendan Jul 17 '22 at 03:12
0

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.

Jeff Silverman
  • 692
  • 1
  • 8
  • 15
  • but I still don't quite get why it is hard to swap pages of kernel when kernel is located entire in physical memory. In reality, paging out refers to the process of OS evicts pages from physical memory into swap space. So this is really confusing – torez233 Jul 17 '22 at 00:23
  • It's not so much that it's hard in the sense that it is difficult. It's hard in the sense that it makes the computer less efficient. Every process in the system shares the kernel, so a page fault in the kernel is going to affect every process. The value of a page of kernel is multiplied by the number of processes on the system. By way of contrast, every page of a shared library is of less value, it is multiplied by the number of processes that share it. A page of process is only useful to that one process - its value is low. – Jeff Silverman Jul 18 '22 at 01:25
  • if I understand u correctly, you're saying a page of kernel is more valuable than a page of process from user space, as kernel is basically shared among every process. If that is the case, wouldn't it be better if we keep kernel entirely present in physical memory thus every access to its page won't hit page fault? – torez233 Jul 18 '22 at 02:36
0

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.

chairs
  • 1
  • 1