Documentation/mm/highmem.rst

Source file repositories/reference/linux-study-clean/Documentation/mm/highmem.rst

File Facts

System
Linux kernel
Corpus path
Documentation/mm/highmem.rst
Extension
.rst
Size
9607 bytes
Lines
214
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

====================
High Memory Handling
====================

By: Peter Zijlstra <a.p.zijlstra@chello.nl>

.. contents:: :local:

What Is High Memory?
====================

High memory (highmem) is used when the size of physical memory approaches or
exceeds the maximum size of virtual memory.  At that point it becomes
impossible for the kernel to keep all of the available physical memory mapped
at all times.  This means the kernel needs to start using temporary mappings of
the pieces of physical memory that it wants to access.

The part of (physical) memory not covered by a permanent mapping is what we
refer to as 'highmem'.  There are various architecture dependent constraints on
where exactly that border lies.

In the i386 arch, for example, we choose to map the kernel into every process's
VM space so that we don't have to pay the full TLB invalidation costs for
kernel entry/exit.  This means the available virtual memory space (4GiB on
i386) has to be divided between user and kernel space.

The traditional split for architectures using this approach is 3:1, 3GiB for
userspace and the top 1GiB for kernel space::

		+--------+ 0xffffffff
		| Kernel |
		+--------+ 0xc0000000
		|        |
		| User   |
		|        |
		+--------+ 0x00000000

This means that the kernel can at most map 1GiB of physical memory at any one
time, but because we need virtual address space for other things - including
temporary maps to access the rest of the physical memory - the actual direct
map will typically be less (usually around ~896MiB).

Other architectures that have mm context tagged TLBs can have separate kernel
and user maps.  Some hardware (like some ARMs), however, have limited virtual
space when they use mm context tags.


Temporary Virtual Mappings
==========================

The kernel contains several ways of creating temporary mappings. The following
list shows them in order of preference of use.

* kmap_local_page(), kmap_local_folio() - These functions are used to create
  short term mappings. They can be invoked from any context (including
  interrupts) but the mappings can only be used in the context which acquired
  them. The only differences between them consist in the first taking a pointer
  to a struct page and the second taking a pointer to struct folio and the byte
  offset within the folio which identifies the page.

  These functions should always be used, whereas kmap_atomic() and kmap() have
  been deprecated.

  These mappings are thread-local and CPU-local, meaning that the mapping
  can only be accessed from within this thread and the thread is bound to the
  CPU while the mapping is active. Although preemption is never disabled by
  this function, the CPU can not be unplugged from the system via
  CPU-hotplug until the mapping is disposed.

  It's valid to take pagefaults in a local kmap region, unless the context

Annotation

Implementation Notes