Chapter3:MemoryManagement
/* Manipulate page tables */
...
flush_tlb_mm(oldmm);The sequence of operations — cache flushing, memory manipulation, and TLB flushing — is important
for two reasons:❑ If the sequence were reversed, another CPU in a multiprocessor system could take the wrong
information from the process table after the TLBshave been flushed but before the correct infor-
mation is supplied.
❑ Some architectures require the presence of ‘‘virtual-to-physical‘‘ transformation rules in the TLB
when the cache is flushed (caches with this property are referred to asstrict).flush_tlb_mmmust
executeafterflush_cache_mmto guarantee that this is the case.Some control functions apply specifically to data caches (flush_dcache_...) or instruction caches
(flush_icache_...).❑ flush_dcache_page(struct page *page)helps prevent alias problems that arise if a cache may
contain several entries (with different virtual addresses) that point to the same page in memory.
It is always invoked when the kernel writes to a page in the page cache or when it wants to read
data from a page that is also mapped in userspace. This routine gives each architecture in which
alias problems can occur an opportunity to prevent such problems.
❑ flush_icache_range(unsigned long start, unsigned long end)is invoked when the kernel
writes data to kernel memory (betweenstartandend) for subsequent execution. A standard
example of this scenario is when a module is loaded into the kernel. The binary data are first
copied to RAM and are then executed.flush_icache_rangeensures that data and instruction
caches do not interfere with each other if implemented separately.
❑ flush_icache_user_range(*vma, *page, addr, len)is a special function for the ptrace mecha-
nism. It is needed to propagate changes to the address space of a traced process.It is beyond the scope of this book to discuss the implementation details of the cache and TLB control
functions. Too much background knowledge on thestructure of the underlying processor (and
the subtle problems involved) would be required for a full understanding of the implementation
details.3.8 Summary
This chapter has discussed many aspects of memory management. Our focus lies on physical memory
management, but the connection between virtual andphysical memory via page tables has also been cov-
ered. Although the architecture-specific details in thisarea differ greatly among the various architectures
supported by Linux, an architecture-independent set of data structures and functions allows generic code
to manipulate the page tables. However, some architecture-specific code is required before the generic
view is enabled, and this code runs during the boot process.Once the kernel is up and running, memory management is handled by two layers: The buddy system
is responsible for the management of physical page frames, while the slab allocator must handle small
allocations and provides an in-kernel equivalent to themallocfunction family known from userland
programming.