view Documentation/networking/baycom.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
3 Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
5 !!NEW!! (04/98) The drivers for the baycom modems have been split into
6 separate drivers as they did not share any code, and the driver
7 and device names have changed.
9 This document describes the Linux Kernel Drivers for simple Baycom style
10 amateur radio modems.
12 The following drivers are available:
14 baycom_ser_fdx:
15 This driver supports the SER12 modems either full or half duplex.
16 Its baud rate may be changed via the `baud' module parameter,
17 therefore it supports just about every bit bang modem on a
18 serial port. Its devices are called bcsf0 through bcsf3.
19 This is the recommended driver for SER12 type modems,
20 however if you have a broken UART clone that does not have working
21 delta status bits, you may try baycom_ser_hdx.
23 baycom_ser_hdx:
24 This is an alternative driver for SER12 type modems.
25 It only supports half duplex, and only 1200 baud. Its devices
26 are called bcsh0 through bcsh3. Use this driver only if baycom_ser_fdx
27 does not work with your UART.
29 baycom_par:
30 This driver supports the par96 and picpar modems.
31 Its devices are called bcp0 through bcp3.
33 baycom_epp:
34 This driver supports the EPP modem.
35 Its devices are called bce0 through bce3.
36 This driver is work-in-progress.
38 The following modems are supported:
40 ser12: This is a very simple 1200 baud AFSK modem. The modem consists only
41 of a modulator/demodulator chip, usually a TI TCM3105. The computer
42 is responsible for regenerating the receiver bit clock, as well as
43 for handling the HDLC protocol. The modem connects to a serial port,
44 hence the name. Since the serial port is not used as an async serial
45 port, the kernel driver for serial ports cannot be used, and this
46 driver only supports standard serial hardware (8250, 16450, 16550)
48 par96: This is a modem for 9600 baud FSK compatible to the G3RUH standard.
49 The modem does all the filtering and regenerates the receiver clock.
50 Data is transferred from and to the PC via a shift register.
51 The shift register is filled with 16 bits and an interrupt is signalled.
52 The PC then empties the shift register in a burst. This modem connects
53 to the parallel port, hence the name. The modem leaves the
54 implementation of the HDLC protocol and the scrambler polynomial to
55 the PC.
57 picpar: This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
58 is protocol compatible to par96, but uses only three low power ICs
59 and can therefore be fed from the parallel port and does not require
60 an additional power supply. Furthermore, it incorporates a carrier
61 detect circuitry.
63 EPP: This is a high-speed modem adaptor that connects to an enhanced parallel port.
64 Its target audience is users working over a high speed hub (76.8kbit/s).
66 eppfpga: This is a redesign of the EPP adaptor.
70 All of the above modems only support half duplex communications. However,
71 the driver supports the KISS (see below) fullduplex command. It then simply
72 starts to send as soon as there's a packet to transmit and does not care
73 about DCD, i.e. it starts to send even if there's someone else on the channel.
74 This command is required by some implementations of the DAMA channel
75 access protocol.
78 The Interface of the drivers
80 Unlike previous drivers, these drivers are no longer character devices,
81 but they are now true kernel network interfaces. Installation is therefore
82 simple. Once installed, four interfaces named bc{sf,sh,p,e}[0-3] are available.
83 sethdlc from the ax25 utilities may be used to set driver states etc.
84 Users of userland AX.25 stacks may use the net2kiss utility (also available
85 in the ax25 utilities package) to convert packets of a network interface
86 to a KISS stream on a pseudo tty. There's also a patch available from
87 me for WAMPES which allows attaching a kernel network interface directly.
90 Configuring the driver
92 Every time a driver is inserted into the kernel, it has to know which
93 modems it should access at which ports. This can be done with the setbaycom
94 utility. If you are only using one modem, you can also configure the
95 driver from the insmod command line (or by means of an option line in
96 /etc/modprobe.conf).
98 Examples:
99 modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
100 sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4
102 Both lines configure the first port to drive a ser12 modem at the first
103 serial port (COM1 under DOS). The * in the mode parameter instructs the driver to use
104 the software DCD algorithm (see below).
106 insmod baycom_par mode="picpar" iobase=0x378
107 sethdlc -i bcp0 -p mode "picpar" io 0x378
109 Both lines configure the first port to drive a picpar modem at the
110 first parallel port (LPT1 under DOS). (Note: picpar implies
111 hardware DCD, par96 implies software DCD).
113 The channel access parameters can be set with sethdlc -a or kissparms.
114 Note that both utilities interpret the values slightly differently.
117 Hardware DCD versus Software DCD
119 To avoid collisions on the air, the driver must know when the channel is
120 busy. This is the task of the DCD circuitry/software. The driver may either
121 utilise a software DCD algorithm (options=1) or use a DCD signal from
122 the hardware (options=0).
124 ser12: if software DCD is utilised, the radio's squelch should always be
125 open. It is highly recommended to use the software DCD algorithm,
126 as it is much faster than most hardware squelch circuitry. The
127 disadvantage is a slightly higher load on the system.
129 par96: the software DCD algorithm for this type of modem is rather poor.
130 The modem simply does not provide enough information to implement
131 a reasonable DCD algorithm in software. Therefore, if your radio
132 feeds the DCD input of the PAR96 modem, the use of the hardware
133 DCD circuitry is recommended.
135 picpar: the picpar modem features a builtin DCD hardware, which is highly
136 recommended.
140 Compatibility with the rest of the Linux kernel
142 The serial driver and the baycom serial drivers compete
143 for the same hardware resources. Of course only one driver can access a given
144 interface at a time. The serial driver grabs all interfaces it can find at
145 startup time. Therefore the baycom drivers subsequently won't be able to
146 access a serial port. You might therefore find it necessary to release
147 a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
148 # is the number of the interface. The baycom drivers do not reserve any
149 ports at startup, unless one is specified on the 'insmod' command line. Another
150 method to solve the problem is to compile all drivers as modules and
151 leave it to kmod to load the correct driver depending on the application.
153 The parallel port drivers (baycom_par, baycom_epp) now use the parport subsystem
154 to arbitrate the ports between different client drivers.
156 vy 73s de
157 Tom Sailer, sailer@ife.ee.ethz.ch
158 hb9jnx @ hb9w.ampr.org