ia64/linux-2.6.18-xen.hg

view Documentation/arm/mem_alignment @ 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 Too many problems poped up because of unnoticed misaligned memory access in
2 kernel code lately. Therefore the alignment fixup is now unconditionally
3 configured in for SA11x0 based targets. According to Alan Cox, this is a
4 bad idea to configure it out, but Russell King has some good reasons for
5 doing so on some f***ed up ARM architectures like the EBSA110. However
6 this is not the case on many design I'm aware of, like all SA11x0 based
7 ones.
9 Of course this is a bad idea to rely on the alignment trap to perform
10 unaligned memory access in general. If those access are predictable, you
11 are better to use the macros provided by include/asm/unaligned.h. The
12 alignment trap can fixup misaligned access for the exception cases, but at
13 a high performance cost. It better be rare.
15 Now for user space applications, it is possible to configure the alignment
16 trap to SIGBUS any code performing unaligned access (good for debugging bad
17 code), or even fixup the access by software like for kernel code. The later
18 mode isn't recommended for performance reasons (just think about the
19 floating point emulation that works about the same way). Fix your code
20 instead!
22 Please note that randomly changing the behaviour without good thought is
23 real bad - it changes the behaviour of all unaligned instructions in user
24 space, and might cause programs to fail unexpectedly.
26 To change the alignment trap behavior, simply echo a number into
27 /proc/sys/debug/alignment. The number is made up from various bits:
29 bit behavior when set
30 --- -----------------
32 0 A user process performing an unaligned memory access
33 will cause the kernel to print a message indicating
34 process name, pid, pc, instruction, address, and the
35 fault code.
37 1 The kernel will attempt to fix up the user process
38 performing the unaligned access. This is of course
39 slow (think about the floating point emulator) and
40 not recommended for production use.
42 2 The kernel will send a SIGBUS signal to the user process
43 performing the unaligned access.
45 Note that not all combinations are supported - only values 0 through 5.
46 (6 and 7 don't make sense).
48 For example, the following will turn on the warnings, but without
49 fixing up or sending SIGBUS signals:
51 echo 1 > /proc/sys/debug/alignment
53 You can also read the content of the same file to get statistical
54 information on unaligned access occurrences plus the current mode of
55 operation for user space code.
58 Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001.