Lines Matching +full:keep +full:- +full:a +full:- +full:live

5 By: Peter Zijlstra <a.p.zijlstra@chello.nl>
14 impossible for the kernel to keep all of the available physical memory mapped
18 The part of (physical) memory not covered by a permanent mapping is what we
30 		+--------+ 0xffffffff
32 		+--------+ 0xc0000000
36 		+--------+ 0x00000000
39 time, but because we need virtual address space for other things - including
40 temporary maps to access the rest of the physical memory - the actual direct
54 * kmap_local_page(), kmap_local_folio() - These functions are used to create
57   them. The only differences between them consist in the first taking a pointer
58   to a struct page and the second taking a pointer to struct folio and the byte
64   These mappings are thread-local and CPU-local, meaning that the mapping
68   CPU-hotplug until the mapping is disposed.
70   It's valid to take pagefaults in a local kmap region, unless the context
74   disable preemption because, when context switches to a different task, the
83   temporarily mapped. Therefore, users may call a plain page_address()
91   be absolutely sure to keep the use of the return address local to the
99   Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain
116   This permits a very short duration mapping of a single page.  Since the
125   Each call of kmap_atomic() in the kernel creates a non-preemptible section
126   and disable pagefaults. This could be a source of unwanted latency. Therefore
140   This should be used to make short duration mapping of a single page with no
142   space is restricted and protected by a global lock for synchronization. When
148   block when the mapping space is fully utilized until a slot becomes
151   All the above work is necessary if a mapping must last for a relatively
152   long time but the bulk of high-memory mappings in the kernel are
153   short-lived and only used in one place. This means that the cost of
159   On 64-bit systems, calls to kmap_local_page(), kmap_atomic() and kmap() have
160   no real work to do because a 64-bit address space is more than sufficient to
163 * vmap().  This can be used to make a long duration mapping of multiple
164   physical pages into a contiguous virtual space.  It needs global
174 If CONFIG_HIGHMEM is not set, then the kernel will try and create a mapping
175 simply with a bit of arithmetic that will convert the page struct address into
176 a pointer to the page contents rather than juggling mappings about.  In such a
177 case, the unmap operation may be a null operation.
180 highmem.  In such a case, the arithmetic approach will also be used.
187 of RAM into your 32-bit machine.  This has a number of consequences:
189 * Linux needs a page-frame structure for each page in the system and the
190   pageframes need to live in the permanent mapping, which means:
192 * you can have 896M/sizeof(struct page) page-frames at most; with struct
193   page being 32-bytes that would end up being something in the order of 112G
195   page-frames in that memory...
197 * PAE makes your page tables larger - which slows the system down as more
202 The general recommendation is that you don't use more than 8GiB on a 32-bit
203 machine - although more might work for you and your workload, you're pretty
204 much on your own - don't expect kernel developers to really care much if things
211 .. kernel-doc:: include/linux/highmem.h
212 .. kernel-doc:: mm/highmem.c
213 .. kernel-doc:: include/linux/highmem-internal.h