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

7 By: Peter Zijlstra <a.p.zijlstra@chello.nl>
16 impossible for the kernel to keep all of the available physical memory mapped
20 The part of (physical) memory not covered by a permanent mapping is what we
32 		+--------+ 0xffffffff
34 		+--------+ 0xc0000000
38 		+--------+ 0x00000000
41 time, but because we need virtual address space for other things - including
42 temporary maps to access the rest of the physical memory - the actual direct
55 * vmap().  This can be used to make a long duration mapping of multiple
56   physical pages into a contiguous virtual space.  It needs global
59 * kmap().  This permits a short duration mapping of a single page.  It needs
61   deadlocks when using in a nested fashion, and so it is not recommended for
64 * kmap_atomic().  This permits a very short duration mapping of a single
79 wants to access the contents of a page that might be allocated from high memory
80 (see __GFP_HIGHMEM), for example a page in the pagecache.  The API has two
81 functions, and they can be used in a manner similar to the following::
99 another you need to keep the kmap_atomic calls strictly nested, like::
116 If CONFIG_HIGHMEM is not set, then the kernel will try and create a mapping
117 simply with a bit of arithmetic that will convert the page struct address into
118 a pointer to the page contents rather than juggling mappings about.  In such a
119 case, the unmap operation may be a null operation.
122 highmem.  In such a case, the arithmetic approach will also be used.
129 of RAM into your 32-bit machine.  This has a number of consequences:
131 * Linux needs a page-frame structure for each page in the system and the
132   pageframes need to live in the permanent mapping, which means:
134 * you can have 896M/sizeof(struct page) page-frames at most; with struct
135   page being 32-bytes that would end up being something in the order of 112G
137   page-frames in that memory...
139 * PAE makes your page tables larger - which slows the system down as more
144 The general recommendation is that you don't use more than 8GiB on a 32-bit
145 machine - although more might work for you and your workload, you're pretty
146 much on your own - don't expect kernel developers to really care much if things