view Documentation/usb/hotplug.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 In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
4 into the bus with power on. In most cases, users expect the devices to become
5 immediately usable. That means the system must do many things, including:
7 - Find a driver that can handle the device. That may involve
8 loading a kernel module; newer drivers can use module-init-tools
9 to publish their device (and class) support to user utilities.
11 - Bind a driver to that device. Bus frameworks do that using a
12 device driver's probe() routine.
14 - Tell other subsystems to configure the new device. Print
15 queues may need to be enabled, networks brought up, disk
16 partitions mounted, and so on. In some cases these will
17 be driver-specific actions.
19 This involves a mix of kernel mode and user mode actions. Making devices
20 be immediately usable means that any user mode actions can't wait for an
21 administrator to do them: the kernel must trigger them, either passively
22 (triggering some monitoring daemon to invoke a helper program) or
23 actively (calling such a user mode helper program directly).
25 Those triggered actions must support a system's administrative policies;
26 such programs are called "policy agents" here. Typically they involve
27 shell scripts that dispatch to more familiar administration tools.
29 Because some of those actions rely on information about drivers (metadata)
30 that is currently available only when the drivers are dynamically linked,
31 you get the best hotplugging when you configure a highly modular system.
34 KERNEL HOTPLUG HELPER (/sbin/hotplug)
36 When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
37 /proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
38 That parameter names a program which the kernel may invoke at various times.
40 The /sbin/hotplug program can be invoked by any subsystem as part of its
41 reaction to a configuration change, from a thread in that subsystem.
42 Only one parameter is required: the name of a subsystem being notified of
43 some kernel event. That name is used as the first key for further event
44 dispatch; any other argument and environment parameters are specified by
45 the subsystem making that invocation.
47 Hotplug software and other resources is available at:
49 http://linux-hotplug.sourceforge.net
51 Mailing list information is also available at that site.
54 --------------------------------------------------------------------------
59 The USB subsystem currently invokes /sbin/hotplug when USB devices
60 are added or removed from system. The invocation is done by the kernel
61 hub daemon thread [khubd], or else as part of root hub initialization
62 (done by init, modprobe, kapmd, etc). Its single command line parameter
63 is the string "usb", and it passes these environment variables:
65 ACTION ... "add", "remove"
66 PRODUCT ... USB vendor, product, and version codes (hex)
67 TYPE ... device class codes (decimal)
68 INTERFACE ... interface 0 class codes (decimal)
70 If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is
71 the pathname of the device, and is useful for devices with multiple and/or
72 alternate interfaces that complicate driver selection. By design, USB
73 hotplugging is independent of "usbdevfs": you can do most essential parts
74 of USB device setup without using that filesystem, and without running a
75 user mode daemon to detect changes in system configuration.
77 Currently available policy agent implementations can load drivers for
78 modules, and can invoke driver-specific setup scripts. The newest ones
79 leverage USB module-init-tools support. Later agents might unload drivers.
84 Current versions of module-init-tools will create a "modules.usbmap" file
85 which contains the entries from each driver's MODULE_DEVICE_TABLE. Such
86 files can be used by various user mode policy agents to make sure all the
87 right driver modules get loaded, either at boot time or later.
89 See <linux/usb.h> for full information about such table entries; or look
90 at existing drivers. Each table entry describes one or more criteria to
91 be used when matching a driver to a device or class of devices. The
92 specific criteria are identified by bits set in "match_flags", paired
93 with field values. You can construct the criteria directly, or with
94 macros such as these, and use driver_info to store more information.
96 USB_DEVICE (vendorId, productId)
97 ... matching devices with specified vendor and product ids
98 USB_DEVICE_VER (vendorId, productId, lo, hi)
99 ... like USB_DEVICE with lo <= productversion <= hi
100 USB_INTERFACE_INFO (class, subclass, protocol)
101 ... matching specified interface class info
102 USB_DEVICE_INFO (class, subclass, protocol)
103 ... matching specified device class info
105 A short example, for a driver that supports several specific USB devices
106 and their quirks, might have a MODULE_DEVICE_TABLE like this:
108 static const struct usb_device_id mydriver_id_table = {
109 { USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X },
110 { USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z },
111 ...
112 { } /* end with an all-zeroes entry */
113 }
114 MODULE_DEVICE_TABLE (usb, mydriver_id_table);
116 Most USB device drivers should pass these tables to the USB subsystem as
117 well as to the module management subsystem. Not all, though: some driver
118 frameworks connect using interfaces layered over USB, and so they won't
119 need such a "struct usb_driver".
121 Drivers that connect directly to the USB subsystem should be declared
122 something like this:
124 static struct usb_driver mydriver = {
125 .name = "mydriver",
126 .id_table = mydriver_id_table,
127 .probe = my_probe,
128 .disconnect = my_disconnect,
130 /*
131 if using the usb chardev framework:
132 .minor = MY_USB_MINOR_START,
133 .fops = my_file_ops,
134 if exposing any operations through usbdevfs:
135 .ioctl = my_ioctl,
136 */
137 }
139 When the USB subsystem knows about a driver's device ID table, it's used when
140 choosing drivers to probe(). The thread doing new device processing checks
141 drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and
142 device descriptors for the device. It will only call probe() if there is a
143 match, and the third argument to probe() will be the entry that matched.
145 If you don't provide an id_table for your driver, then your driver may get
146 probed for each new device; the third parameter to probe() will be null.