ia64/linux-2.6.18-xen.hg

view Documentation/locks.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
children
line source
1 File Locking Release Notes
3 Andy Walker <andy@lysaker.kvaerner.no>
5 12 May 1997
8 1. What's New?
9 --------------
11 1.1 Broken Flock Emulation
12 --------------------------
14 The old flock(2) emulation in the kernel was swapped for proper BSD
15 compatible flock(2) support in the 1.3.x series of kernels. With the
16 release of the 2.1.x kernel series, support for the old emulation has
17 been totally removed, so that we don't need to carry this baggage
18 forever.
20 This should not cause problems for anybody, since everybody using a
21 2.1.x kernel should have updated their C library to a suitable version
22 anyway (see the file "Documentation/Changes".)
24 1.2 Allow Mixed Locks Again
25 ---------------------------
27 1.2.1 Typical Problems - Sendmail
28 ---------------------------------
29 Because sendmail was unable to use the old flock() emulation, many sendmail
30 installations use fcntl() instead of flock(). This is true of Slackware 3.0
31 for example. This gave rise to some other subtle problems if sendmail was
32 configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
33 file with fcntl() at the same time as the GDBM routines tried to lock this
34 file with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
35 over time, or under a very heavy mail load, would eventually cause the kernel
36 to lock solid with deadlocked processes.
39 1.2.2 The Solution
40 ------------------
41 The solution I have chosen, after much experimentation and discussion,
42 is to make flock() and fcntl() locks oblivious to each other. Both can
43 exists, and neither will have any effect on the other.
45 I wanted the two lock styles to be cooperative, but there were so many
46 race and deadlock conditions that the current solution was the only
47 practical one. It puts us in the same position as, for example, SunOS
48 4.1.x and several other commercial Unices. The only OS's that support
49 cooperative flock()/fcntl() are those that emulate flock() using
50 fcntl(), with all the problems that implies.
53 1.3 Mandatory Locking As A Mount Option
54 ---------------------------------------
56 Mandatory locking, as described in 'Documentation/mandatory.txt' was prior
57 to this release a general configuration option that was valid for all
58 mounted filesystems. This had a number of inherent dangers, not the least
59 of which was the ability to freeze an NFS server by asking it to read a
60 file for which a mandatory lock existed.
62 From this release of the kernel, mandatory locking can be turned on and off
63 on a per-filesystem basis, using the mount options 'mand' and 'nomand'.
64 The default is to disallow mandatory locking. The intention is that
65 mandatory locking only be enabled on a local filesystem as the specific need
66 arises.