view Documentation/networking/policy-routing.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 Classes
2 -------
4 "Class" is a complete routing table in common sense.
5 I.e. it is tree of nodes (destination prefix, tos, metric)
6 with attached information: gateway, device etc.
7 This tree is looked up as specified in RFC1812
8 1. Basic match
9 2. Longest match
10 3. Weak TOS.
11 4. Metric. (should not be in kernel space, but they are)
12 5. Additional pruning rules. (not in kernel space).
14 We have two special type of nodes:
15 REJECT - abort route lookup and return an error value.
16 THROW - abort route lookup in this class.
19 Currently the number of classes is limited to 255
20 (0 is reserved for "not specified class")
22 Three classes are builtin:
24 RT_CLASS_LOCAL=255 - local interface addresses,
25 broadcasts, nat addresses.
27 RT_CLASS_MAIN=254 - all normal routes are put there
28 by default.
30 RT_CLASS_DEFAULT=253 - if ip_fib_model==1, then
31 normal default routes are put there, if ip_fib_model==2
32 all gateway routes are put there.
35 Rules
36 -----
37 Rule is a record of (src prefix, src interface, tos, dst prefix)
38 with attached information.
40 Rule types:
41 RTP_ROUTE - lookup in attached class
42 RTP_NAT - lookup in attached class and if a match is found,
43 translate packet source address.
44 RTP_MASQUERADE - lookup in attached class and if a match is found,
45 masquerade packet as sourced by us.
46 RTP_DROP - silently drop the packet.
47 RTP_REJECT - drop the packet and send ICMP NET UNREACHABLE.
48 RTP_PROHIBIT - drop the packet and send ICMP COMM. ADM. PROHIBITED.
50 Rule flags:
51 RTRF_LOG - log route creations.
52 RTRF_VALVE - One way route (used with masquerading)
54 Default setup:
56 root@amber:/pub/ip-routing # iproute -r
57 Kernel routing policy rules
58 Pref Source Destination TOS Iface Cl
59 0 default default 00 * 255
60 254 default default 00 * 254
61 255 default default 00 * 253
64 Lookup algorithm
65 ----------------
67 We scan rules list, and if a rule is matched, apply it.
68 If a route is found, return it.
69 If it is not found or a THROW node was matched, continue
70 to scan rules.
72 Applications
73 ------------
75 1. Just ignore classes. All the routes are put into MAIN class
76 (and/or into DEFAULT class).
78 HOWTO: iproute add PREFIX [ tos TOS ] [ gw GW ] [ dev DEV ]
79 [ metric METRIC ] [ reject ] ... (look at iproute utility)
81 or use route utility from current net-tools.
83 2. Opposite case. Just forget all that you know about routing
84 tables. Every rule is supplied with its own gateway, device
85 info. record. This approach is not appropriate for automated
86 route maintenance, but it is ideal for manual configuration.
88 HOWTO: iproute addrule [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
89 [ dev INPUTDEV] [ pref PREFERENCE ] route [ gw GATEWAY ]
90 [ dev OUTDEV ] .....
92 Warning: As of now the size of the routing table in this
93 approach is limited to 256. If someone likes this model, I'll
94 relax this limitation.
96 3. OSPF classes (see RFC1583, RFC1812 E.3.3)
97 Very clean, stable and robust algorithm for OSPF routing
98 domains. Unfortunately, it is not widely used in the Internet.
100 Proposed setup:
101 255 local addresses
102 254 interface routes
103 253 ASE routes with external metric
104 252 ASE routes with internal metric
105 251 inter-area routes
106 250 intra-area routes for 1st area
107 249 intra-area routes for 2nd area
108 etc.
110 Rules:
111 iproute addrule class 253
112 iproute addrule class 252
113 iproute addrule class 251
114 iproute addrule to a-prefix-for-1st-area class 250
115 iproute addrule to another-prefix-for-1st-area class 250
116 ...
117 iproute addrule to a-prefix-for-2nd-area class 249
118 ...
120 Area classes must be terminated with reject record.
121 iproute add default reject class 250
122 iproute add default reject class 249
123 ...
125 4. The Variant Router Requirements Algorithm (RFC1812 E.3.2)
126 Create 16 classes for different TOS values.
127 It is a funny, but pretty useless algorithm.
128 I listed it just to show the power of new routing code.
130 5. All the variety of combinations......
134 -----
136 Gated does not understand classes, but it will work
137 happily in MAIN+DEFAULT. All policy routes can be set
138 and maintained manually.
141 --------------
142 route.c has a compilation time switch CONFIG_IP_LOCAL_RT_POLICY.
143 If it is set, locally originated packets are routed
144 using all the policy list. This is not very convenient and
145 pretty ambiguous when used with NAT and masquerading.
146 I set it to FALSE by default.
149 Alexey Kuznetov
150 kuznet@ms2.inr.ac.ru