view Documentation/networking/ltpc.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 This is the ALPHA version of the ltpc driver.
3 In order to use it, you will need at least version 1.3.3 of the
4 netatalk package, and the Apple or Farallon LocalTalk PC card.
5 There are a number of different LocalTalk cards for the PC; this
6 driver applies only to the one with the 65c02 processor chip on it.
8 To include it in the kernel, select the CONFIG_LTPC switch in the
9 configuration dialog. You can also compile it as a module.
11 While the driver will attempt to autoprobe the I/O port address, IRQ
12 line, and DMA channel of the card, this does not always work. For
13 this reason, you should be prepared to supply these parameters
14 yourself. (see "Card Configuration" below for how to determine or
15 change the settings on your card)
17 When the driver is compiled into the kernel, you can add a line such
18 as the following to your /etc/lilo.conf:
20 append="ltpc=0x240,9,1"
22 where the parameters (in order) are the port address, IRQ, and DMA
23 channel. The second and third values can be omitted, in which case
24 the driver will try to determine them itself.
26 If you load the driver as a module, you can pass the parameters "io=",
27 "irq=", and "dma=" on the command line with insmod or modprobe, or add
28 them as options in /etc/modprobe.conf:
30 alias lt0 ltpc # autoload the module when the interface is configured
31 options ltpc io=0x240 irq=9 dma=1
33 Before starting up the netatalk demons (perhaps in rc.local), you
34 need to add a line such as:
36 /sbin/ifconfig lt0
38 The address is unimportant - however, the card needs to be configured
39 with ifconfig so that Netatalk can find it.
41 The appropriate netatalk configuration depends on whether you are
42 attached to a network that includes AppleTalk routers or not. If,
43 like me, you are simply connecting to your home Macintoshes and
44 printers, you need to set up netatalk to "seed". The way I do this
45 is to have the lines
47 dummy -seed -phase 2 -net 2000 -addr 2000.26 -zone "1033"
48 lt0 -seed -phase 1 -net 1033 -addr 1033.27 -zone "1033"
50 in my atalkd.conf. What is going on here is that I need to fool
51 netatalk into thinking that there are two AppleTalk interfaces
52 present; otherwise, it refuses to seed. This is a hack, and a more
53 permanent solution would be to alter the netatalk code. Also, make
54 sure you have the correct name for the dummy interface - If it's
55 compiled as a module, you will need to refer to it as "dummy0" or some
56 such.
58 If you are attached to an extended AppleTalk network, with routers on
59 it, then you don't need to fool around with this -- the appropriate
60 line in atalkd.conf is
62 lt0 -phase 1
64 --------------------------------------
66 Card Configuration:
68 The interrupts and so forth are configured via the dipswitch on the
69 board. Set the switches so as not to conflict with other hardware.
71 Interrupts -- set at most one. If none are set, the driver uses
72 polled mode. Because the card was developed in the XT era, the
73 original documentation refers to IRQ2. Since you'll be running
74 this on an AT (or later) class machine, that really means IRQ9.
76 SW1 IRQ 4
77 SW2 IRQ 3
78 SW3 IRQ 9 (2 in original card documentation only applies to XT)
81 DMA -- choose DMA 1 or 3, and set both corresponding switches.
83 SW4 DMA 3
84 SW5 DMA 1
85 SW6 DMA 3
86 SW7 DMA 1
89 I/O address -- choose one.
91 SW8 220 / 240
93 --------------------------------------
95 IP:
97 Yes, it is possible to do IP over LocalTalk. However, you can't just
98 treat the LocalTalk device like an ordinary Ethernet device, even if
99 that's what it looks like to Netatalk.
101 Instead, you follow the same procedure as for doing IP in EtherTalk.
102 See Documentation/networking/ipddp.txt for more information about the
103 kernel driver and userspace tools needed.
105 --------------------------------------
107 BUGS:
109 IRQ autoprobing often doesn't work on a cold boot. To get around
110 this, either compile the driver as a module, or pass the parameters
111 for the card to the kernel as described above.
113 Also, as usual, autoprobing is not recommended when you use the driver
114 as a module. (though it usually works at boot time, at least)
116 Polled mode is *really* slow sometimes, but this seems to depend on
117 the configuration of the network.
119 It may theoretically be possible to use two LTPC cards in the same
120 machine, but this is unsupported, so if you really want to do this,
121 you'll probably have to hack the initialization code a bit.
123 ______________________________________
126 Thanks to Alan Cox for helpful discussions early on in this
127 work, and to Denis Hainsworth for doing the bleeding-edge testing.
129 -- Bradford Johnson <bradford@math.umn.edu>
131 -- Updated 11/09/1998 by David Huggins-Daines <dhd@debian.org>