ia64/linux-2.6.18-xen.hg

view drivers/mtd/chips/Kconfig @ 897:329ea0ccb344

balloon: try harder to balloon up under memory pressure.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Jun 05 14:01:20 2009 +0100 (2009-06-05)
parents 831230e53067
children
line source
1 # drivers/mtd/chips/Kconfig
2 # $Id: Kconfig,v 1.18 2005/11/07 11:14:22 gleixner Exp $
4 menu "RAM/ROM/Flash chip drivers"
5 depends on MTD!=n
7 config MTD_CFI
8 tristate "Detect flash chips by Common Flash Interface (CFI) probe"
9 depends on MTD
10 select MTD_GEN_PROBE
11 help
12 The Common Flash Interface specification was developed by Intel,
13 AMD and other flash manufactures that provides a universal method
14 for probing the capabilities of flash devices. If you wish to
15 support any device that is CFI-compliant, you need to enable this
16 option. Visit <http://www.amd.com/products/nvd/overview/cfi.html>
17 for more information on CFI.
19 config MTD_JEDECPROBE
20 tristate "Detect non-CFI AMD/JEDEC-compatible flash chips"
21 depends on MTD
22 select MTD_GEN_PROBE
23 help
24 This option enables JEDEC-style probing of flash chips which are not
25 compatible with the Common Flash Interface, but will use the common
26 CFI-targetted flash drivers for any chips which are identified which
27 are in fact compatible in all but the probe method. This actually
28 covers most AMD/Fujitsu-compatible chips and also non-CFI
29 Intel chips.
31 config MTD_GEN_PROBE
32 tristate
34 config MTD_CFI_ADV_OPTIONS
35 bool "Flash chip driver advanced configuration options"
36 depends on MTD_GEN_PROBE
37 help
38 If you need to specify a specific endianness for access to flash
39 chips, or if you wish to reduce the size of the kernel by including
40 support for only specific arrangements of flash chips, say 'Y'. This
41 option does not directly affect the code, but will enable other
42 configuration options which allow you to do so.
44 If unsure, say 'N'.
46 choice
47 prompt "Flash cmd/query data swapping"
48 depends on MTD_CFI_ADV_OPTIONS
49 default MTD_CFI_NOSWAP
51 config MTD_CFI_NOSWAP
52 bool "NO"
53 ---help---
54 This option defines the way in which the CPU attempts to arrange
55 data bits when writing the 'magic' commands to the chips. Saying
56 'NO', which is the default when CONFIG_MTD_CFI_ADV_OPTIONS isn't
57 enabled, means that the CPU will not do any swapping; the chips
58 are expected to be wired to the CPU in 'host-endian' form.
59 Specific arrangements are possible with the BIG_ENDIAN_BYTE and
60 LITTLE_ENDIAN_BYTE, if the bytes are reversed.
62 If you have a LART, on which the data (and address) lines were
63 connected in a fashion which ensured that the nets were as short
64 as possible, resulting in a bit-shuffling which seems utterly
65 random to the untrained eye, you need the LART_ENDIAN_BYTE option.
67 Yes, there really exists something sicker than PDP-endian :)
69 config MTD_CFI_BE_BYTE_SWAP
70 bool "BIG_ENDIAN_BYTE"
72 config MTD_CFI_LE_BYTE_SWAP
73 bool "LITTLE_ENDIAN_BYTE"
75 endchoice
77 config MTD_CFI_GEOMETRY
78 bool "Specific CFI Flash geometry selection"
79 depends on MTD_CFI_ADV_OPTIONS
80 help
81 This option does not affect the code directly, but will enable
82 some other configuration options which would allow you to reduce
83 the size of the kernel by including support for only certain
84 arrangements of CFI chips. If unsure, say 'N' and all options
85 which are supported by the current code will be enabled.
87 config MTD_MAP_BANK_WIDTH_1
88 bool "Support 8-bit buswidth" if MTD_CFI_GEOMETRY
89 default y
90 help
91 If you wish to support CFI devices on a physical bus which is
92 8 bits wide, say 'Y'.
94 config MTD_MAP_BANK_WIDTH_2
95 bool "Support 16-bit buswidth" if MTD_CFI_GEOMETRY
96 default y
97 help
98 If you wish to support CFI devices on a physical bus which is
99 16 bits wide, say 'Y'.
101 config MTD_MAP_BANK_WIDTH_4
102 bool "Support 32-bit buswidth" if MTD_CFI_GEOMETRY
103 default y
104 help
105 If you wish to support CFI devices on a physical bus which is
106 32 bits wide, say 'Y'.
108 config MTD_MAP_BANK_WIDTH_8
109 bool "Support 64-bit buswidth" if MTD_CFI_GEOMETRY
110 default n
111 help
112 If you wish to support CFI devices on a physical bus which is
113 64 bits wide, say 'Y'.
115 config MTD_MAP_BANK_WIDTH_16
116 bool "Support 128-bit buswidth" if MTD_CFI_GEOMETRY
117 default n
118 help
119 If you wish to support CFI devices on a physical bus which is
120 128 bits wide, say 'Y'.
122 config MTD_MAP_BANK_WIDTH_32
123 bool "Support 256-bit buswidth" if MTD_CFI_GEOMETRY
124 default n
125 help
126 If you wish to support CFI devices on a physical bus which is
127 256 bits wide, say 'Y'.
129 config MTD_CFI_I1
130 bool "Support 1-chip flash interleave" if MTD_CFI_GEOMETRY
131 default y
132 help
133 If your flash chips are not interleaved - i.e. you only have one
134 flash chip addressed by each bus cycle, then say 'Y'.
136 config MTD_CFI_I2
137 bool "Support 2-chip flash interleave" if MTD_CFI_GEOMETRY
138 default y
139 help
140 If your flash chips are interleaved in pairs - i.e. you have two
141 flash chips addressed by each bus cycle, then say 'Y'.
143 config MTD_CFI_I4
144 bool "Support 4-chip flash interleave" if MTD_CFI_GEOMETRY
145 default n
146 help
147 If your flash chips are interleaved in fours - i.e. you have four
148 flash chips addressed by each bus cycle, then say 'Y'.
150 config MTD_CFI_I8
151 bool "Support 8-chip flash interleave" if MTD_CFI_GEOMETRY
152 default n
153 help
154 If your flash chips are interleaved in eights - i.e. you have eight
155 flash chips addressed by each bus cycle, then say 'Y'.
157 config MTD_OTP
158 bool "Protection Registers aka one-time programmable (OTP) bits"
159 depends on MTD_CFI_ADV_OPTIONS
160 default n
161 help
162 This enables support for reading, writing and locking so called
163 "Protection Registers" present on some flash chips.
164 A subset of them are pre-programmed at the factory with a
165 unique set of values. The rest is user-programmable.
167 The user-programmable Protection Registers contain one-time
168 programmable (OTP) bits; when programmed, register bits cannot be
169 erased. Each Protection Register can be accessed multiple times to
170 program individual bits, as long as the register remains unlocked.
172 Each Protection Register has an associated Lock Register bit. When a
173 Lock Register bit is programmed, the associated Protection Register
174 can only be read; it can no longer be programmed. Additionally,
175 because the Lock Register bits themselves are OTP, when programmed,
176 Lock Register bits cannot be erased. Therefore, when a Protection
177 Register is locked, it cannot be unlocked.
179 This feature should therefore be used with extreme care. Any mistake
180 in the programming of OTP bits will waste them.
182 config MTD_CFI_INTELEXT
183 tristate "Support for Intel/Sharp flash chips"
184 depends on MTD_GEN_PROBE
185 select MTD_CFI_UTIL
186 help
187 The Common Flash Interface defines a number of different command
188 sets which a CFI-compliant chip may claim to implement. This code
189 provides support for one of those command sets, used on Intel
190 StrataFlash and other parts.
192 config MTD_CFI_AMDSTD
193 tristate "Support for AMD/Fujitsu flash chips"
194 depends on MTD_GEN_PROBE
195 select MTD_CFI_UTIL
196 help
197 The Common Flash Interface defines a number of different command
198 sets which a CFI-compliant chip may claim to implement. This code
199 provides support for one of those command sets, used on chips
200 including the AMD Am29LV320.
202 config MTD_CFI_STAA
203 tristate "Support for ST (Advanced Architecture) flash chips"
204 depends on MTD_GEN_PROBE
205 select MTD_CFI_UTIL
206 help
207 The Common Flash Interface defines a number of different command
208 sets which a CFI-compliant chip may claim to implement. This code
209 provides support for one of those command sets.
211 config MTD_CFI_UTIL
212 tristate
214 config MTD_RAM
215 tristate "Support for RAM chips in bus mapping"
216 depends on MTD
217 help
218 This option enables basic support for RAM chips accessed through
219 a bus mapping driver.
221 config MTD_ROM
222 tristate "Support for ROM chips in bus mapping"
223 depends on MTD
224 help
225 This option enables basic support for ROM chips accessed through
226 a bus mapping driver.
228 config MTD_ABSENT
229 tristate "Support for absent chips in bus mapping"
230 depends on MTD
231 help
232 This option enables support for a dummy probing driver used to
233 allocated placeholder MTD devices on systems that have socketed
234 or removable media. Use of this driver as a fallback chip probe
235 preserves the expected registration order of MTD device nodes on
236 the system regardless of media presence. Device nodes created
237 with this driver will return -ENODEV upon access.
239 config MTD_OBSOLETE_CHIPS
240 depends on MTD
241 bool "Older (theoretically obsoleted now) drivers for non-CFI chips"
242 help
243 This option does not enable any code directly, but will allow you to
244 select some other chip drivers which are now considered obsolete,
245 because the generic CONFIG_JEDECPROBE code above should now detect
246 the chips which are supported by these drivers, and allow the generic
247 CFI-compatible drivers to drive the chips. Say 'N' here unless you have
248 already tried the CONFIG_JEDECPROBE method and reported its failure
249 to the MTD mailing list at <linux-mtd@lists.infradead.org>
251 config MTD_AMDSTD
252 tristate "AMD compatible flash chip support (non-CFI)"
253 depends on MTD && MTD_OBSOLETE_CHIPS && BROKEN
254 help
255 This option enables support for flash chips using AMD-compatible
256 commands, including some which are not CFI-compatible and hence
257 cannot be used with the CONFIG_MTD_CFI_AMDSTD option.
259 It also works on AMD compatible chips that do conform to CFI.
261 config MTD_SHARP
262 tristate "pre-CFI Sharp chip support"
263 depends on MTD && MTD_OBSOLETE_CHIPS
264 help
265 This option enables support for flash chips using Sharp-compatible
266 commands, including some which are not CFI-compatible and hence
267 cannot be used with the CONFIG_MTD_CFI_INTELxxx options.
269 config MTD_JEDEC
270 tristate "JEDEC device support"
271 depends on MTD && MTD_OBSOLETE_CHIPS && BROKEN
272 help
273 Enable older older JEDEC flash interface devices for self
274 programming flash. It is commonly used in older AMD chips. It is
275 only called JEDEC because the JEDEC association
276 <http://www.jedec.org/> distributes the identification codes for the
277 chips.
279 config MTD_XIP
280 bool "XIP aware MTD support"
281 depends on !SMP && (MTD_CFI_INTELEXT || MTD_CFI_AMDSTD) && EXPERIMENTAL && ARCH_MTD_XIP
282 default y if XIP_KERNEL
283 help
284 This allows MTD support to work with flash memory which is also
285 used for XIP purposes. If you're not sure what this is all about
286 then say N.
288 endmenu