annotate Documentation/networking/x25-iface.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
rev   line source
ian@0 1 X.25 Device Driver Interface 1.1
ian@0 2
ian@0 3 Jonathan Naylor 26.12.96
ian@0 4
ian@0 5 This is a description of the messages to be passed between the X.25 Packet
ian@0 6 Layer and the X.25 device driver. They are designed to allow for the easy
ian@0 7 setting of the LAPB mode from within the Packet Layer.
ian@0 8
ian@0 9 The X.25 device driver will be coded normally as per the Linux device driver
ian@0 10 standards. Most X.25 device drivers will be moderately similar to the
ian@0 11 already existing Ethernet device drivers. However unlike those drivers, the
ian@0 12 X.25 device driver has a state associated with it, and this information
ian@0 13 needs to be passed to and from the Packet Layer for proper operation.
ian@0 14
ian@0 15 All messages are held in sk_buff's just like real data to be transmitted
ian@0 16 over the LAPB link. The first byte of the skbuff indicates the meaning of
ian@0 17 the rest of the skbuff, if any more information does exist.
ian@0 18
ian@0 19
ian@0 20 Packet Layer to Device Driver
ian@0 21 -----------------------------
ian@0 22
ian@0 23 First Byte = 0x00
ian@0 24
ian@0 25 This indicates that the rest of the skbuff contains data to be transmitted
ian@0 26 over the LAPB link. The LAPB link should already exist before any data is
ian@0 27 passed down.
ian@0 28
ian@0 29 First Byte = 0x01
ian@0 30
ian@0 31 Establish the LAPB link. If the link is already established then the connect
ian@0 32 confirmation message should be returned as soon as possible.
ian@0 33
ian@0 34 First Byte = 0x02
ian@0 35
ian@0 36 Terminate the LAPB link. If it is already disconnected then the disconnect
ian@0 37 confirmation message should be returned as soon as possible.
ian@0 38
ian@0 39 First Byte = 0x03
ian@0 40
ian@0 41 LAPB parameters. To be defined.
ian@0 42
ian@0 43
ian@0 44 Device Driver to Packet Layer
ian@0 45 -----------------------------
ian@0 46
ian@0 47 First Byte = 0x00
ian@0 48
ian@0 49 This indicates that the rest of the skbuff contains data that has been
ian@0 50 received over the LAPB link.
ian@0 51
ian@0 52 First Byte = 0x01
ian@0 53
ian@0 54 LAPB link has been established. The same message is used for both a LAPB
ian@0 55 link connect_confirmation and a connect_indication.
ian@0 56
ian@0 57 First Byte = 0x02
ian@0 58
ian@0 59 LAPB link has been terminated. This same message is used for both a LAPB
ian@0 60 link disconnect_confirmation and a disconnect_indication.
ian@0 61
ian@0 62 First Byte = 0x03
ian@0 63
ian@0 64 LAPB parameters. To be defined.
ian@0 65
ian@0 66
ian@0 67
ian@0 68 Possible Problems
ian@0 69 =================
ian@0 70
ian@0 71 (Henner Eisen, 2000-10-28)
ian@0 72
ian@0 73 The X.25 packet layer protocol depends on a reliable datalink service.
ian@0 74 The LAPB protocol provides such reliable service. But this reliability
ian@0 75 is not preserved by the Linux network device driver interface:
ian@0 76
ian@0 77 - With Linux 2.4.x (and above) SMP kernels, packet ordering is not
ian@0 78 preserved. Even if a device driver calls netif_rx(skb1) and later
ian@0 79 netif_rx(skb2), skb2 might be delivered to the network layer
ian@0 80 earlier that skb1.
ian@0 81 - Data passed upstream by means of netif_rx() might be dropped by the
ian@0 82 kernel if the backlog queue is congested.
ian@0 83
ian@0 84 The X.25 packet layer protocol will detect this and reset the virtual
ian@0 85 call in question. But many upper layer protocols are not designed to
ian@0 86 handle such N-Reset events gracefully. And frequent N-Reset events
ian@0 87 will always degrade performance.
ian@0 88
ian@0 89 Thus, driver authors should make netif_rx() as reliable as possible:
ian@0 90
ian@0 91 SMP re-ordering will not occur if the driver's interrupt handler is
ian@0 92 always executed on the same CPU. Thus,
ian@0 93
ian@0 94 - Driver authors should use irq affinity for the interrupt handler.
ian@0 95
ian@0 96 The probability of packet loss due to backlog congestion can be
ian@0 97 reduced by the following measures or a combination thereof:
ian@0 98
ian@0 99 (1) Drivers for kernel versions 2.4.x and above should always check the
ian@0 100 return value of netif_rx(). If it returns NET_RX_DROP, the
ian@0 101 driver's LAPB protocol must not confirm reception of the frame
ian@0 102 to the peer.
ian@0 103 This will reliably suppress packet loss. The LAPB protocol will
ian@0 104 automatically cause the peer to re-transmit the dropped packet
ian@0 105 later.
ian@0 106 The lapb module interface was modified to support this. Its
ian@0 107 data_indication() method should now transparently pass the
ian@0 108 netif_rx() return value to the (lapb mopdule) caller.
ian@0 109 (2) Drivers for kernel versions 2.2.x should always check the global
ian@0 110 variable netdev_dropping when a new frame is received. The driver
ian@0 111 should only call netif_rx() if netdev_dropping is zero. Otherwise
ian@0 112 the driver should not confirm delivery of the frame and drop it.
ian@0 113 Alternatively, the driver can queue the frame internally and call
ian@0 114 netif_rx() later when netif_dropping is 0 again. In that case, delivery
ian@0 115 confirmation should also be deferred such that the internal queue
ian@0 116 cannot grow to much.
ian@0 117 This will not reliably avoid packet loss, but the probability
ian@0 118 of packet loss in netif_rx() path will be significantly reduced.
ian@0 119 (3) Additionally, driver authors might consider to support
ian@0 120 CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
ian@0 121 when a previously congested backlog queue becomes empty again.
ian@0 122 The driver could uses this for flow-controlling the peer by means
ian@0 123 of the LAPB protocol's flow-control service.