Handling Page Faults

All architectures on which Linux runs support the concept of page faults that are triggered when a page in virtual address space is accessed but is not present in physical memory. The page fault instructs the kernel to read the missing data from the swap area or from another backing store, possibly by first deleting other pages to make space for the new data.

Page fault handling is in two parts. First, strongly processor-dependent (assembler) code must be used to intercept the page fault and query the associated data. Second, a system-independent part of code is responsible for the further handling of the situation. Because of optimizations used by the kernel when managing processes, it is not sufficient to simply search for the relevant page in the backing store and load it into the RAM memory because the page fault may have been triggered for other reasons (see Chapter 4). For example, copy-on-write pages may be involved; these are copied only when a write access is executed after a process has forked. Page faults also occur with demand paging, where the pages of a mapping are loaded only when actually needed. I ignore these problems here, however, and focus on the situation in which a swapped-out page must be reloaded into memory.

Once again, there's more to be done than just finding the page in the swap area. As access to the hard disk is even slower than usual if the read head has to move to a new position (disk seek), the kernel uses a readahead mechanism to guess which pages will be needed next and also includes these in the read operation. Thanks to the clustering method mentioned above, the Read/Write head ideally only moves forward and does not have to jump backward and forward when reading consecutive pages.

Continue reading here: Shrinking Kernel Caches

Was this article helpful?

0 0