view Documentation/arm/Porting @ 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
line source
1 Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html
3 Initial definitions
4 -------------------
6 The following symbol definitions rely on you knowing the translation that
7 __virt_to_phys() does for your machine. This macro converts the passed
8 virtual address to a physical address. Normally, it is simply:
10 phys = virt - PAGE_OFFSET + PHYS_OFFSET
13 Decompressor Symbols
14 --------------------
17 Start address of decompressor. There's no point in talking about
18 virtual or physical addresses here, since the MMU will be off at
19 the time when you call the decompressor code. You normally call
20 the kernel at this address to start it booting. This doesn't have
21 to be located in RAM, it can be in flash or other read-only or
22 read-write addressable medium.
25 Start address of zero-initialised work area for the decompressor.
26 This must be pointing at RAM. The decompressor will zero initialise
27 this for you. Again, the MMU will be off.
30 This is the address where the decompressed kernel will be written,
31 and eventually executed. The following constraint must be valid:
33 __virt_to_phys(TEXTADDR) == ZRELADDR
35 The initial part of the kernel is carefully coded to be position
36 independent.
39 Physical address to place the initial RAM disk. Only relevant if
40 you are using the bootpImage stuff (which only works on the old
41 struct param_struct).
44 Virtual address of the initial RAM disk. The following constraint
45 must be valid:
47 __virt_to_phys(INITRD_VIRT) == INITRD_PHYS
50 Physical address of the struct param_struct or tag list, giving the
51 kernel various parameters about its execution environment.
54 Kernel Symbols
55 --------------
58 Physical start address of the first bank of RAM.
61 Virtual start address of the first bank of RAM. During the kernel
62 boot phase, virtual address PAGE_OFFSET will be mapped to physical
63 address PHYS_OFFSET, along with any other mappings you supply.
64 This should be the same value as TASK_SIZE.
67 The maximum size of a user process in bytes. Since user space
68 always starts at zero, this is the maximum address that a user
69 process can access+1. The user space stack grows down from this
70 address.
72 Any virtual address below TASK_SIZE is deemed to be user process
73 area, and therefore managed dynamically on a process by process
74 basis by the kernel. I'll call this the user segment.
76 Anything above TASK_SIZE is common to all processes. I'll call
77 this the kernel segment.
79 (In other words, you can't put IO mappings below TASK_SIZE, and
80 hence PAGE_OFFSET).
83 Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
84 This is where the kernel image ends up. With the latest kernels,
85 it must be located at 32768 bytes into a 128MB region. Previous
86 kernels placed a restriction of 256MB here.
89 Virtual address for the kernel data segment. Must not be defined
90 when using the decompressor.
94 Virtual addresses bounding the vmalloc() area. There must not be
95 any static mappings in this area; vmalloc will overwrite them.
96 The addresses must also be in the kernel segment (see above).
97 Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
98 last virtual RAM address (found using variable high_memory).
101 Offset normally incorporated into VMALLOC_START to provide a hole
102 between virtual RAM and the vmalloc area. We do this to allow
103 out of bounds memory accesses (eg, something writing off the end
104 of the mapped memory map) to be caught. Normally set to 8MB.
106 Architecture Specific Macros
107 ----------------------------
109 BOOT_MEM(pram,pio,vio)
110 `pram' specifies the physical start address of RAM. Must always
111 be present, and should be the same as PHYS_OFFSET.
113 `pio' is the physical address of an 8MB region containing IO for
114 use with the debugging macros in arch/arm/kernel/debug-armv.S.
116 `vio' is the virtual address of the 8MB debugging region.
118 It is expected that the debugging region will be re-initialised
119 by the architecture specific code later in the code (via the
120 MAPIO function).
123 Same as, and see PARAMS_PHYS.
125 FIXUP(func)
126 Machine specific fixups, run before memory subsystems have been
127 initialised.
129 MAPIO(func)
130 Machine specific function to map IO areas (including the debug
131 region above).
133 INITIRQ(func)
134 Machine specific function to initialise interrupts.