view Documentation/highuid.txt @ 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 Notes on the change from 16-bit UIDs to 32-bit UIDs:
3 - kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t
4 when communicating between user and kernel space in an ioctl or data
5 structure.
7 - kernel code should use uid_t and gid_t in kernel-private structures and
8 code.
10 What's left to be done for 32-bit UIDs on all Linux architectures:
12 - Disk quotas have an interesting limitation that is not related to the
13 maximum UID/GID. They are limited by the maximum file size on the
14 underlying filesystem, because quota records are written at offsets
15 corresponding to the UID in question.
16 Further investigation is needed to see if the quota system can cope
17 properly with huge UIDs. If it can deal with 64-bit file offsets on all
18 architectures, this should not be a problem.
20 - Decide whether or not to keep backwards compatibility with the system
21 accounting file, or if we should break it as the comments suggest
22 (currently, the old 16-bit UID and GID are still written to disk, and
23 part of the former pad space is used to store separate 32-bit UID and
24 GID)
26 - Need to validate that OS emulation calls the 16-bit UID
27 compatibility syscalls, if the OS being emulated used 16-bit UIDs, or
28 uses the 32-bit UID system calls properly otherwise.
30 This affects at least:
31 SunOS emulation
32 Solaris emulation
33 iBCS on Intel
35 sparc32 emulation on sparc64
36 (need to support whatever new 32-bit UID system calls are added to
37 sparc32)
39 - Validate that all filesystems behave properly.
41 At present, 32-bit UIDs _should_ work for:
42 ext2
43 ufs
44 isofs
45 nfs
46 coda
47 udf
49 Ioctl() fixups have been made for:
50 ncpfs
51 smbfs
53 Filesystems with simple fixups to prevent 16-bit UID wraparound:
54 minix
55 sysv
56 qnx4
58 Other filesystems have not been checked yet.
60 - The ncpfs and smpfs filesystems can not presently use 32-bit UIDs in
61 all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but
62 more are needed. (as well as new user<->kernel data structures)
64 - The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k,
65 sh, and sparc32. Fixing this is probably not that important, but would
66 require adding a new ELF section.
68 - The ioctl()s used to control the in-kernel NFS server only support
69 16-bit UIDs on arm, i386, m68k, sh, and sparc32.
71 - make sure that the UID mapping feature of AX25 networking works properly
72 (it should be safe because it's always used a 32-bit integer to
73 communicate between user and kernel)
76 Chris Wing
77 wingc@umich.edu
79 last updated: January 11, 2000