ia64/linux-2.6.18-xen.hg

view Documentation/networking/driver.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 Document about softnet driver issues
3 Transmit path guidelines:
5 1) The hard_start_xmit method must never return '1' under any
6 normal circumstances. It is considered a hard error unless
7 there is no way your device can tell ahead of time when it's
8 transmit function will become busy.
10 Instead it must maintain the queue properly. For example,
11 for a driver implementing scatter-gather this means:
13 static int drv_hard_start_xmit(struct sk_buff *skb,
14 struct net_device *dev)
15 {
16 struct drv *dp = dev->priv;
18 lock_tx(dp);
19 ...
20 /* This is a hard error log it. */
21 if (TX_BUFFS_AVAIL(dp) <= (skb_shinfo(skb)->nr_frags + 1)) {
22 netif_stop_queue(dev);
23 unlock_tx(dp);
24 printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
25 dev->name);
26 return 1;
27 }
29 ... queue packet to card ...
30 ... update tx consumer index ...
32 if (TX_BUFFS_AVAIL(dp) <= (MAX_SKB_FRAGS + 1))
33 netif_stop_queue(dev);
35 ...
36 unlock_tx(dp);
37 ...
38 }
40 And then at the end of your TX reclaimation event handling:
42 if (netif_queue_stopped(dp->dev) &&
43 TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1))
44 netif_wake_queue(dp->dev);
46 For a non-scatter-gather supporting card, the three tests simply become:
48 /* This is a hard error log it. */
49 if (TX_BUFFS_AVAIL(dp) <= 0)
51 and:
53 if (TX_BUFFS_AVAIL(dp) == 0)
55 and:
57 if (netif_queue_stopped(dp->dev) &&
58 TX_BUFFS_AVAIL(dp) > 0)
59 netif_wake_queue(dp->dev);
61 2) Do not forget to update netdev->trans_start to jiffies after
62 each new tx packet is given to the hardware.
64 3) Do not forget that once you return 0 from your hard_start_xmit
65 method, it is your driver's responsibility to free up the SKB
66 and in some finite amount of time.
68 For example, this means that it is not allowed for your TX
69 mitigation scheme to let TX packets "hang out" in the TX
70 ring unreclaimed forever if no new TX packets are sent.
71 This error can deadlock sockets waiting for send buffer room
72 to be freed up.
74 If you return 1 from the hard_start_xmit method, you must not keep
75 any reference to that SKB and you must not attempt to free it up.
77 Probing guidelines:
79 1) Any hardware layer address you obtain for your device should
80 be verified. For example, for ethernet check it with
81 linux/etherdevice.h:is_valid_ether_addr()
83 Close/stop guidelines:
85 1) After the dev->stop routine has been called, the hardware must
86 not receive or transmit any data. All in flight packets must
87 be aborted. If necessary, poll or wait for completion of
88 any reset commands.
90 2) The dev->stop routine will be called by unregister_netdevice
91 if device is still UP.