Documentation/core-api/cachetlb.rst

Source file repositories/reference/linux-study-clean/Documentation/core-api/cachetlb.rst

File Facts

System
Linux kernel
Corpus path
Documentation/core-api/cachetlb.rst
Extension
.rst
Size
17148 bytes
Lines
399
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==================================
Cache and TLB Flushing Under Linux
==================================

:Author: David S. Miller <davem@redhat.com>

This document describes the cache/tlb flushing interfaces called
by the Linux VM subsystem.  It enumerates over each interface,
describes its intended purpose, and what side effect is expected
after the interface is invoked.

The side effects described below are stated for a uniprocessor
implementation, and what is to happen on that single processor.  The
SMP cases are a simple extension, in that you just extend the
definition such that the side effect for a particular interface occurs
on all processors in the system.  Don't let this scare you into
thinking SMP cache/tlb flushing must be so inefficient, this is in
fact an area where many optimizations are possible.  For example,
if it can be proven that a user address space has never executed
on a cpu (see mm_cpumask()), one need not perform a flush
for this address space on that cpu.

First, the TLB flushing interfaces, since they are the simplest.  The
"TLB" is abstracted under Linux as something the cpu uses to cache
virtual-->physical address translations obtained from the software
page tables.  Meaning that if the software page tables change, it is
possible for stale translations to exist in this "TLB" cache.
Therefore when software page table changes occur, the kernel will
invoke one of the following flush methods _after_ the page table
changes occur:

1) ``void flush_tlb_all(void)``

	The most severe flush of all.  After this interface runs,
	any previous page table modification whatsoever will be
	visible to the cpu.

	This is usually invoked when the kernel page tables are
	changed, since such translations are "global" in nature.

2) ``void flush_tlb_mm(struct mm_struct *mm)``

	This interface flushes an entire user address space from
	the TLB.  After running, this interface must make sure that
	any previous page table modifications for the address space
	'mm' will be visible to the cpu.  That is, after running,
	there will be no entries in the TLB for 'mm'.

	This interface is used to handle whole address space
	page table operations such as what happens during
	fork, and exec.

3) ``void flush_tlb_range(struct vm_area_struct *vma,
   unsigned long start, unsigned long end)``

	Here we are flushing a specific range of (user) virtual
	address translations from the TLB.  After running, this
	interface must make sure that any previous page table
	modifications for the address space 'vma->vm_mm' in the range
	'start' to 'end-1' will be visible to the cpu.  That is, after
	running, there will be no entries in the TLB for 'mm' for
	virtual addresses in the range 'start' to 'end-1'.

	The "vma" is the backing store being used for the region.
	Primarily, this is used for munmap() type operations.

	The interface is provided in hopes that the port can find
	a suitably efficient method for removing multiple page
	sized translations from the TLB, instead of having the kernel
	call flush_tlb_page (see below) for each entry which may be

Annotation

Implementation Notes