Root/
Source at commit b386be689295730688885552666ea40b2e639b14 created 11 years 11 months ago. By Maarten ter Huurne, Revert "MIPS: JZ4740: reset: Initialize hibernate wakeup counters." | |
---|---|
1 | config SELECT_MEMORY_MODEL |
2 | def_bool y |
3 | depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL |
4 | |
5 | choice |
6 | prompt "Memory model" |
7 | depends on SELECT_MEMORY_MODEL |
8 | default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT |
9 | default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT |
10 | default FLATMEM_MANUAL |
11 | |
12 | config FLATMEM_MANUAL |
13 | bool "Flat Memory" |
14 | depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE |
15 | help |
16 | This option allows you to change some of the ways that |
17 | Linux manages its memory internally. Most users will |
18 | only have one option here: FLATMEM. This is normal |
19 | and a correct option. |
20 | |
21 | Some users of more advanced features like NUMA and |
22 | memory hotplug may have different options here. |
23 | DISCONTIGMEM is an more mature, better tested system, |
24 | but is incompatible with memory hotplug and may suffer |
25 | decreased performance over SPARSEMEM. If unsure between |
26 | "Sparse Memory" and "Discontiguous Memory", choose |
27 | "Discontiguous Memory". |
28 | |
29 | If unsure, choose this option (Flat Memory) over any other. |
30 | |
31 | config DISCONTIGMEM_MANUAL |
32 | bool "Discontiguous Memory" |
33 | depends on ARCH_DISCONTIGMEM_ENABLE |
34 | help |
35 | This option provides enhanced support for discontiguous |
36 | memory systems, over FLATMEM. These systems have holes |
37 | in their physical address spaces, and this option provides |
38 | more efficient handling of these holes. However, the vast |
39 | majority of hardware has quite flat address spaces, and |
40 | can have degraded performance from the extra overhead that |
41 | this option imposes. |
42 | |
43 | Many NUMA configurations will have this as the only option. |
44 | |
45 | If unsure, choose "Flat Memory" over this option. |
46 | |
47 | config SPARSEMEM_MANUAL |
48 | bool "Sparse Memory" |
49 | depends on ARCH_SPARSEMEM_ENABLE |
50 | help |
51 | This will be the only option for some systems, including |
52 | memory hotplug systems. This is normal. |
53 | |
54 | For many other systems, this will be an alternative to |
55 | "Discontiguous Memory". This option provides some potential |
56 | performance benefits, along with decreased code complexity, |
57 | but it is newer, and more experimental. |
58 | |
59 | If unsure, choose "Discontiguous Memory" or "Flat Memory" |
60 | over this option. |
61 | |
62 | endchoice |
63 | |
64 | config DISCONTIGMEM |
65 | def_bool y |
66 | depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL |
67 | |
68 | config SPARSEMEM |
69 | def_bool y |
70 | depends on (!SELECT_MEMORY_MODEL && ARCH_SPARSEMEM_ENABLE) || SPARSEMEM_MANUAL |
71 | |
72 | config FLATMEM |
73 | def_bool y |
74 | depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL |
75 | |
76 | config FLAT_NODE_MEM_MAP |
77 | def_bool y |
78 | depends on !SPARSEMEM |
79 | |
80 | # |
81 | # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's |
82 | # to represent different areas of memory. This variable allows |
83 | # those dependencies to exist individually. |
84 | # |
85 | config NEED_MULTIPLE_NODES |
86 | def_bool y |
87 | depends on DISCONTIGMEM || NUMA |
88 | |
89 | config HAVE_MEMORY_PRESENT |
90 | def_bool y |
91 | depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM |
92 | |
93 | # |
94 | # SPARSEMEM_EXTREME (which is the default) does some bootmem |
95 | # allocations when memory_present() is called. If this cannot |
96 | # be done on your architecture, select this option. However, |
97 | # statically allocating the mem_section[] array can potentially |
98 | # consume vast quantities of .bss, so be careful. |
99 | # |
100 | # This option will also potentially produce smaller runtime code |
101 | # with gcc 3.4 and later. |
102 | # |
103 | config SPARSEMEM_STATIC |
104 | bool |
105 | |
106 | # |
107 | # Architecture platforms which require a two level mem_section in SPARSEMEM |
108 | # must select this option. This is usually for architecture platforms with |
109 | # an extremely sparse physical address space. |
110 | # |
111 | config SPARSEMEM_EXTREME |
112 | def_bool y |
113 | depends on SPARSEMEM && !SPARSEMEM_STATIC |
114 | |
115 | config SPARSEMEM_VMEMMAP_ENABLE |
116 | bool |
117 | |
118 | config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER |
119 | def_bool y |
120 | depends on SPARSEMEM && X86_64 |
121 | |
122 | config SPARSEMEM_VMEMMAP |
123 | bool "Sparse Memory virtual memmap" |
124 | depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE |
125 | default y |
126 | help |
127 | SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise |
128 | pfn_to_page and page_to_pfn operations. This is the most |
129 | efficient option when sufficient kernel resources are available. |
130 | |
131 | config HAVE_MEMBLOCK |
132 | boolean |
133 | |
134 | config HAVE_MEMBLOCK_NODE_MAP |
135 | boolean |
136 | |
137 | config ARCH_DISCARD_MEMBLOCK |
138 | boolean |
139 | |
140 | config NO_BOOTMEM |
141 | boolean |
142 | |
143 | # eventually, we can have this option just 'select SPARSEMEM' |
144 | config MEMORY_HOTPLUG |
145 | bool "Allow for memory hot-add" |
146 | depends on SPARSEMEM || X86_64_ACPI_NUMA |
147 | depends on HOTPLUG && ARCH_ENABLE_MEMORY_HOTPLUG |
148 | depends on (IA64 || X86 || PPC_BOOK3S_64 || SUPERH || S390) |
149 | |
150 | config MEMORY_HOTPLUG_SPARSE |
151 | def_bool y |
152 | depends on SPARSEMEM && MEMORY_HOTPLUG |
153 | |
154 | config MEMORY_HOTREMOVE |
155 | bool "Allow for memory hot remove" |
156 | depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE |
157 | depends on MIGRATION |
158 | |
159 | # |
160 | # If we have space for more page flags then we can enable additional |
161 | # optimizations and functionality. |
162 | # |
163 | # Regular Sparsemem takes page flag bits for the sectionid if it does not |
164 | # use a virtual memmap. Disable extended page flags for 32 bit platforms |
165 | # that require the use of a sectionid in the page flags. |
166 | # |
167 | config PAGEFLAGS_EXTENDED |
168 | def_bool y |
169 | depends on 64BIT || SPARSEMEM_VMEMMAP || !SPARSEMEM |
170 | |
171 | # Heavily threaded applications may benefit from splitting the mm-wide |
172 | # page_table_lock, so that faults on different parts of the user address |
173 | # space can be handled with less contention: split it at this NR_CPUS. |
174 | # Default to 4 for wider testing, though 8 might be more appropriate. |
175 | # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock. |
176 | # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes. |
177 | # DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page. |
178 | # |
179 | config SPLIT_PTLOCK_CPUS |
180 | int |
181 | default "999999" if ARM && !CPU_CACHE_VIPT |
182 | default "999999" if PARISC && !PA20 |
183 | default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC |
184 | default "4" |
185 | |
186 | # |
187 | # support for memory compaction |
188 | config COMPACTION |
189 | bool "Allow for memory compaction" |
190 | select MIGRATION |
191 | depends on MMU |
192 | help |
193 | Allows the compaction of memory for the allocation of huge pages. |
194 | |
195 | # |
196 | # support for page migration |
197 | # |
198 | config MIGRATION |
199 | bool "Page migration" |
200 | def_bool y |
201 | depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION |
202 | help |
203 | Allows the migration of the physical location of pages of processes |
204 | while the virtual addresses are not changed. This is useful in |
205 | two situations. The first is on NUMA systems to put pages nearer |
206 | to the processors accessing. The second is when allocating huge |
207 | pages as migration can relocate pages to satisfy a huge page |
208 | allocation instead of reclaiming. |
209 | |
210 | config PHYS_ADDR_T_64BIT |
211 | def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT |
212 | |
213 | config ZONE_DMA_FLAG |
214 | int |
215 | default "0" if !ZONE_DMA |
216 | default "1" |
217 | |
218 | config BOUNCE |
219 | def_bool y |
220 | depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM) |
221 | |
222 | config NR_QUICK |
223 | int |
224 | depends on QUICKLIST |
225 | default "2" if AVR32 |
226 | default "1" |
227 | |
228 | config VIRT_TO_BUS |
229 | def_bool y |
230 | depends on !ARCH_NO_VIRT_TO_BUS |
231 | |
232 | config MMU_NOTIFIER |
233 | bool |
234 | |
235 | config KSM |
236 | bool "Enable KSM for page merging" |
237 | depends on MMU |
238 | help |
239 | Enable Kernel Samepage Merging: KSM periodically scans those areas |
240 | of an application's address space that an app has advised may be |
241 | mergeable. When it finds pages of identical content, it replaces |
242 | the many instances by a single page with that content, so |
243 | saving memory until one or another app needs to modify the content. |
244 | Recommended for use with KVM, or with other duplicative applications. |
245 | See Documentation/vm/ksm.txt for more information: KSM is inactive |
246 | until a program has madvised that an area is MADV_MERGEABLE, and |
247 | root has set /sys/kernel/mm/ksm/run to 1 (if CONFIG_SYSFS is set). |
248 | |
249 | config DEFAULT_MMAP_MIN_ADDR |
250 | int "Low address space to protect from user allocation" |
251 | depends on MMU |
252 | default 4096 |
253 | help |
254 | This is the portion of low virtual memory which should be protected |
255 | from userspace allocation. Keeping a user from writing to low pages |
256 | can help reduce the impact of kernel NULL pointer bugs. |
257 | |
258 | For most ia64, ppc64 and x86 users with lots of address space |
259 | a value of 65536 is reasonable and should cause no problems. |
260 | On arm and other archs it should not be higher than 32768. |
261 | Programs which use vm86 functionality or have some need to map |
262 | this low address space will need CAP_SYS_RAWIO or disable this |
263 | protection by setting the value to 0. |
264 | |
265 | This value can be changed after boot using the |
266 | /proc/sys/vm/mmap_min_addr tunable. |
267 | |
268 | config ARCH_SUPPORTS_MEMORY_FAILURE |
269 | bool |
270 | |
271 | config MEMORY_FAILURE |
272 | depends on MMU |
273 | depends on ARCH_SUPPORTS_MEMORY_FAILURE |
274 | bool "Enable recovery from hardware memory errors" |
275 | help |
276 | Enables code to recover from some memory failures on systems |
277 | with MCA recovery. This allows a system to continue running |
278 | even when some of its memory has uncorrected errors. This requires |
279 | special hardware support and typically ECC memory. |
280 | |
281 | config HWPOISON_INJECT |
282 | tristate "HWPoison pages injector" |
283 | depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS |
284 | select PROC_PAGE_MONITOR |
285 | |
286 | config NOMMU_INITIAL_TRIM_EXCESS |
287 | int "Turn on mmap() excess space trimming before booting" |
288 | depends on !MMU |
289 | default 1 |
290 | help |
291 | The NOMMU mmap() frequently needs to allocate large contiguous chunks |
292 | of memory on which to store mappings, but it can only ask the system |
293 | allocator for chunks in 2^N*PAGE_SIZE amounts - which is frequently |
294 | more than it requires. To deal with this, mmap() is able to trim off |
295 | the excess and return it to the allocator. |
296 | |
297 | If trimming is enabled, the excess is trimmed off and returned to the |
298 | system allocator, which can cause extra fragmentation, particularly |
299 | if there are a lot of transient processes. |
300 | |
301 | If trimming is disabled, the excess is kept, but not used, which for |
302 | long-term mappings means that the space is wasted. |
303 | |
304 | Trimming can be dynamically controlled through a sysctl option |
305 | (/proc/sys/vm/nr_trim_pages) which specifies the minimum number of |
306 | excess pages there must be before trimming should occur, or zero if |
307 | no trimming is to occur. |
308 | |
309 | This option specifies the initial value of this option. The default |
310 | of 1 says that all excess pages should be trimmed. |
311 | |
312 | See Documentation/nommu-mmap.txt for more information. |
313 | |
314 | config TRANSPARENT_HUGEPAGE |
315 | bool "Transparent Hugepage Support" |
316 | depends on X86 && MMU |
317 | select COMPACTION |
318 | help |
319 | Transparent Hugepages allows the kernel to use huge pages and |
320 | huge tlb transparently to the applications whenever possible. |
321 | This feature can improve computing performance to certain |
322 | applications by speeding up page faults during memory |
323 | allocation, by reducing the number of tlb misses and by speeding |
324 | up the pagetable walking. |
325 | |
326 | If memory constrained on embedded, you may want to say N. |
327 | |
328 | choice |
329 | prompt "Transparent Hugepage Support sysfs defaults" |
330 | depends on TRANSPARENT_HUGEPAGE |
331 | default TRANSPARENT_HUGEPAGE_ALWAYS |
332 | help |
333 | Selects the sysfs defaults for Transparent Hugepage Support. |
334 | |
335 | config TRANSPARENT_HUGEPAGE_ALWAYS |
336 | bool "always" |
337 | help |
338 | Enabling Transparent Hugepage always, can increase the |
339 | memory footprint of applications without a guaranteed |
340 | benefit but it will work automatically for all applications. |
341 | |
342 | config TRANSPARENT_HUGEPAGE_MADVISE |
343 | bool "madvise" |
344 | help |
345 | Enabling Transparent Hugepage madvise, will only provide a |
346 | performance improvement benefit to the applications using |
347 | madvise(MADV_HUGEPAGE) but it won't risk to increase the |
348 | memory footprint of applications without a guaranteed |
349 | benefit. |
350 | endchoice |
351 | |
352 | # |
353 | # UP and nommu archs use km based percpu allocator |
354 | # |
355 | config NEED_PER_CPU_KM |
356 | depends on !SMP |
357 | bool |
358 | default y |
359 | |
360 | config CLEANCACHE |
361 | bool "Enable cleancache driver to cache clean pages if tmem is present" |
362 | default n |
363 | help |
364 | Cleancache can be thought of as a page-granularity victim cache |
365 | for clean pages that the kernel's pageframe replacement algorithm |
366 | (PFRA) would like to keep around, but can't since there isn't enough |
367 | memory. So when the PFRA "evicts" a page, it first attempts to use |
368 | cleancache code to put the data contained in that page into |
369 | "transcendent memory", memory that is not directly accessible or |
370 | addressable by the kernel and is of unknown and possibly |
371 | time-varying size. And when a cleancache-enabled |
372 | filesystem wishes to access a page in a file on disk, it first |
373 | checks cleancache to see if it already contains it; if it does, |
374 | the page is copied into the kernel and a disk access is avoided. |
375 | When a transcendent memory driver is available (such as zcache or |
376 | Xen transcendent memory), a significant I/O reduction |
377 | may be achieved. When none is available, all cleancache calls |
378 | are reduced to a single pointer-compare-against-NULL resulting |
379 | in a negligible performance hit. |
380 | |
381 | If unsure, say Y to enable cleancache |
382 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9