view Documentation/networking/3c359.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
4 Release 0.9.0 - Release
5 Jul 17th 2000 Mike Phillips
7 1.2.0 - Final
8 Feb 17th 2002 Mike Phillips
9 Updated for submission to the 2.4.x kernel.
11 Thanks:
12 Terry Murphy from 3Com for tech docs and support,
13 Adam D. Ligas for testing the driver.
15 Note:
16 This driver will NOT work with the 3C339 Token Ring cards, you need
17 to use the tms380 driver instead.
19 Options:
21 The driver accepts three options: ringspeed, pkt_buf_sz and message_level.
23 These options can be specified differently for each card found.
25 ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will
26 make the card autosense the ringspeed and join at the appropriate speed,
27 this will be the default option for most people. 4 or 16 allow you to
28 explicitly force the card to operate at a certain speed. The card will fail
29 if you try to insert it at the wrong speed. (Although some hubs will allow
30 this so be *very* careful). The main purpose for explicitly setting the ring
31 speed is for when the card is first on the ring. In autosense mode, if the card
32 cannot detect any active monitors on the ring it will open at the same speed as
33 its last opening. This can be hazardous if this speed does not match the speed
34 you want the ring to operate at.
36 pkt_buf_sz: This is this initial receive buffer allocation size. This will
37 default to 4096 if no value is entered. You may increase performance of the
38 driver by setting this to a value larger than the network packet size, although
39 the driver now re-sizes buffers based on MTU settings as well.
41 message_level: Controls level of messages created by the driver. Defaults to 0:
42 which only displays start-up and critical messages. Presently any non-zero
43 value will display all soft messages as well. NB This does not turn
44 debugging messages on, that must be done by modified the source code.
46 Variable MTU size:
48 The driver can handle a MTU size upto either 4500 or 18000 depending upon
49 ring speed. The driver also changes the size of the receive buffers as part
50 of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
51 to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
52 position = 296,000 bytes of memory space, plus of course anything
53 necessary for the tx sk_buff's. Remember this is per card, so if you are
54 building routers, gateway's etc, you could start to use a lot of memory
55 real fast.
57 2/17/02 Mike Phillips