view Documentation/networking/multicast.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 Behaviour of Cards Under Multicast
2 ==================================
4 This is how they currently behave, not what the hardware can do--for example,
5 the Lance driver doesn't use its filter, even though the code for loading
6 it is in the DEC Lance-based driver.
8 The following are requirements for multicasting
9 -----------------------------------------------
10 AppleTalk Multicast hardware filtering not important but
11 avoid cards only doing promisc
12 IP-Multicast Multicast hardware filters really help
13 IP-MRoute AllMulti hardware filters are of no help
16 Board Multicast AllMulti Promisc Filter
17 ------------------------------------------------------------------------
18 3c501 YES YES YES Software
19 3c503 YES YES YES Hardware
20 3c505 YES NO YES Hardware
21 3c507 NO NO NO N/A
22 3c509 YES YES YES Software
23 3c59x YES YES YES Software
24 ac3200 YES YES YES Hardware
25 apricot YES PROMISC YES Hardware
26 arcnet NO NO NO N/A
27 at1700 PROMISC PROMISC YES Software
29 cs89x0 YES YES YES Software
30 de4x5 YES YES YES Hardware
31 de600 NO NO NO N/A
32 de620 PROMISC PROMISC YES Software
33 depca YES PROMISC YES Hardware
34 dmfe YES YES YES Software(*)
35 e2100 YES YES YES Hardware
36 eepro YES PROMISC YES Hardware
37 eexpress NO NO NO N/A
38 ewrk3 YES PROMISC YES Hardware
39 hp-plus YES YES YES Hardware
40 hp YES YES YES Hardware
41 hp100 YES YES YES Hardware
42 ibmtr NO NO NO N/A
43 ioc3-eth YES YES YES Hardware
44 lance YES YES YES Software(#)
45 ne YES YES YES Hardware
46 ni52 <------------------ Buggy ------------------>
47 ni65 YES YES YES Software(#)
48 seeq NO NO NO N/A
49 sgiseek <------------------ Buggy ------------------>
50 smc-ultra YES YES YES Hardware
51 sunlance YES YES YES Hardware
52 tulip YES YES YES Hardware
53 wavelan YES PROMISC YES Hardware
54 wd YES YES YES Hardware
55 xirc2ps_cs YES YES YES Hardware
56 znet YES YES YES Software
59 PROMISC = This multicast mode is in fact promiscuous mode. Avoid using
60 cards who go PROMISC on any multicast in a multicast kernel.
62 (#) = Hardware multicast support is not used yet.
63 (*) = Hardware support for Davicom 9132 chipset only.