Kernel – Is the MMU Inside Unix/Linux Kernel or Hardware Device?

Virtual memory is almost a decade older than Unix: there was one in the Burroughs B5000 in 1961. It didn't have an MMU in the modern sense (i.e. based on pages) but provided the same basic functions. IBM System/360 Model 67 in 1965 (still older than Unix) had an MMU. Intel x86 processors didn't get an MMU until the 80386 in 1986.

Implementing a Unix system doesn't actually require an MMU. It does require some form of virtual memory, otherwise implementing the fork system call is prohibitively difficult. The fork system call, to create processes by copying an existing process, was a fundamental part of Unix ever since the very first version, so it did require virtual memory. See D. M. Ritchie and K. Thompson, The UNIX Time-Sharing System, CACM, 1974, §V “Processes and images”.

I don't know the details of the hardware that the first Unix versions ran on, but they did have virtual memory in the form of a segmented architecture. The CPU translated between pointers dereferenced by a program (virtual addresses) and actual locations in memory (physical addresses). The mapping was performed by adding an offset to the virtual address. On each context switch between processes, the register containing the offset was adjusted.

Although virtually all Unix implementations provide process isolation, this was not the case of some historical implementations on hardware that didn't have memory protection (both in the 1970s, and also in the 1980s with MINIX on 8088 and 80286). Memory protection is somewhat orthogonal to address virtualization; an MMU provides both, a simple segmented architecture doesn't, an MPU¹ provides protection without virtualization. There is a Linux implementation for systems without an MMU, uCLinux, but due to the lack of fork many programs can't run (the only supported of fork is vfork which requires an execve call in the child immediately afterwards).

¹ _{An MPU (memory protection unit) records access rights for each page of memory.}

Swap is only valid during a given boot, so all the tracking information is kept in memory. Swapping pages in and out is handled entirely by the kernel, and is transparent to processes. Basically, memory is split up into pages, tracked in page tables; these are structures defined by each CPU architecture. When a page is swapped out, the kernel marks it as invalid; thus, the next time anything tries to access the page, the CPU will fault, which will cause a handler in the kernel to be invoked; it’s this handler’s responsibility to restore the page’s contents.

In Linux, there’s a swap_info structure which describes each swap device or file. Within that structure, a swap_map maps memory pages to blocks in the swap device or file. When a pages is swapped out, the kernel stores the swap_info index and swap_map offset in the corresponding page table entry, which allows it to find the page on disk when necessary. (All supported architectures provide enough space for this in their page tables, but there are limits — e.g. the available space means that Linux can manage at most 64GiB of swap on x86.)

You’ll find a much more detailed description of all this in the “Swap Management” chapter of Mel Gorman’s Understanding the Linux Virtual Memory Manager.