view Documentation/sgi-ioc4.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 The SGI IOC4 PCI device is a bit of a strange beast, so some notes on
2 it are in order.
4 First, even though the IOC4 performs multiple functions, such as an
5 IDE controller, a serial controller, a PS/2 keyboard/mouse controller,
6 and an external interrupt mechanism, it's not implemented as a
7 multifunction device. The consequence of this from a software
8 standpoint is that all these functions share a single IRQ, and
9 they can't all register to own the same PCI device ID. To make
10 matters a bit worse, some of the register blocks (and even registers
11 themselves) present in IOC4 are mixed-purpose between these several
12 functions, meaning that there's no clear "owning" device driver.
14 The solution is to organize the IOC4 driver into several independent
15 drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no
16 PS/2 controller driver as this functionality has never been wired up
17 on a shipping IO card.
19 ioc4
20 ====
21 This is the core (or shim) driver for IOC4. It is responsible for
22 initializing the basic functionality of the chip, and allocating
23 the PCI resources that are shared between the IOC4 functions.
25 This driver also provides registration functions that the other
26 IOC4 drivers can call to make their presence known. Each driver
27 needs to provide a probe and remove function, which are invoked
28 by the core driver at appropriate times. The interface of these
29 IOC4 function probe and remove operations isn't precisely the same
30 as PCI device probe and remove operations, but is logically the
31 same operation.
33 sgiioc4
34 =======
35 This is the IDE driver for IOC4. Its name isn't very descriptive
36 simply for historical reasons (it used to be the only IOC4 driver
37 component). There's not much to say about it other than it hooks
38 up to the ioc4 driver via the appropriate registration, probe, and
39 remove functions.
41 ioc4_serial
42 ===========
43 This is the serial driver for IOC4. There's not much to say about it
44 other than it hooks up to the ioc4 driver via the appropriate registration,
45 probe, and remove functions.