view Documentation/usb/URB.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 Revised: 2000-Dec-05.
2 Again: 2002-Jul-06
3 Again: 2005-Sep-19
7 The USB subsystem now has a substantial section in "The Linux Kernel API"
8 guide (in Documentation/DocBook), generated from the current source
9 code. This particular documentation file isn't particularly current or
10 complete; don't rely on it except for a quick overview.
13 1.1. Basic concept or 'What is an URB?'
15 The basic idea of the new driver is message passing, the message itself is
16 called USB Request Block, or URB for short.
18 - An URB consists of all relevant information to execute any USB transaction
19 and deliver the data and status back.
21 - Execution of an URB is inherently an asynchronous operation, i.e. the
22 usb_submit_urb(urb) call returns immediately after it has successfully
23 queued the requested action.
25 - Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time.
27 - Each URB has a completion handler, which is called after the action
28 has been successfully completed or canceled. The URB also contains a
29 context-pointer for passing information to the completion handler.
31 - Each endpoint for a device logically supports a queue of requests.
32 You can fill that queue, so that the USB hardware can still transfer
33 data to an endpoint while your driver handles completion of another.
34 This maximizes use of USB bandwidth, and supports seamless streaming
35 of data to (or from) devices when using periodic transfer modes.
38 1.2. The URB structure
40 Some of the fields in an URB are:
42 struct urb
43 {
44 // (IN) device and pipe specify the endpoint queue
45 struct usb_device *dev; // pointer to associated USB device
46 unsigned int pipe; // endpoint information
48 unsigned int transfer_flags; // ISO_ASAP, SHORT_NOT_OK, etc.
50 // (IN) all urbs need completion routines
51 void *context; // context for completion routine
52 void (*complete)(struct urb *); // pointer to completion routine
54 // (OUT) status after each completion
55 int status; // returned status
57 // (IN) buffer used for data transfers
58 void *transfer_buffer; // associated data buffer
59 int transfer_buffer_length; // data buffer length
60 int number_of_packets; // size of iso_frame_desc
62 // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
63 int actual_length; // actual data buffer length
65 // (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
66 unsigned char* setup_packet; // setup packet (control only)
68 // Only for PERIODIC transfers (ISO, INTERRUPT)
69 // (IN/OUT) start_frame is set unless ISO_ASAP isn't set
70 int start_frame; // start frame
71 int interval; // polling interval
73 // ISO only: packets are only "best effort"; each can have errors
74 int error_count; // number of errors
75 struct usb_iso_packet_descriptor iso_frame_desc[0];
76 };
78 Your driver must create the "pipe" value using values from the appropriate
79 endpoint descriptor in an interface that it's claimed.
82 1.3. How to get an URB?
84 URBs are allocated with the following call
86 struct urb *usb_alloc_urb(int isoframes, int mem_flags)
88 Return value is a pointer to the allocated URB, 0 if allocation failed.
89 The parameter isoframes specifies the number of isochronous transfer frames
90 you want to schedule. For CTRL/BULK/INT, use 0. The mem_flags parameter
91 holds standard memory allocation flags, letting you control (among other
92 things) whether the underlying code may block or not.
94 To free an URB, use
96 void usb_free_urb(struct urb *urb)
98 You may free an urb that you've submitted, but which hasn't yet been
99 returned to you in a completion callback. It will automatically be
100 deallocated when it is no longer in use.
103 1.4. What has to be filled in?
105 Depending on the type of transaction, there are some inline functions
106 defined in <linux/usb.h> to simplify the initialization, such as
107 fill_control_urb() and fill_bulk_urb(). In general, they need the usb
108 device pointer, the pipe (usual format from usb.h), the transfer buffer,
109 the desired transfer length, the completion handler, and its context.
110 Take a look at the some existing drivers to see how they're used.
112 Flags:
113 For ISO there are two startup behaviors: Specified start_frame or ASAP.
114 For ASAP set URB_ISO_ASAP in transfer_flags.
116 If short packets should NOT be tolerated, set URB_SHORT_NOT_OK in
117 transfer_flags.
120 1.5. How to submit an URB?
122 Just call
124 int usb_submit_urb(struct urb *urb, int mem_flags)
126 The mem_flags parameter, such as SLAB_ATOMIC, controls memory allocation,
127 such as whether the lower levels may block when memory is tight.
129 It immediately returns, either with status 0 (request queued) or some
130 error code, usually caused by the following:
132 - Out of memory (-ENOMEM)
133 - Unplugged device (-ENODEV)
134 - Stalled endpoint (-EPIPE)
135 - Too many queued ISO transfers (-EAGAIN)
136 - Too many requested ISO frames (-EFBIG)
137 - Invalid INT interval (-EINVAL)
138 - More than one packet for INT (-EINVAL)
140 After submission, urb->status is -EINPROGRESS; however, you should never
141 look at that value except in your completion callback.
143 For isochronous endpoints, your completion handlers should (re)submit
144 URBs to the same endpoint with the ISO_ASAP flag, using multi-buffering,
145 to get seamless ISO streaming.
148 1.6. How to cancel an already running URB?
150 There are two ways to cancel an URB you've submitted but which hasn't
151 been returned to your driver yet. For an asynchronous cancel, call
153 int usb_unlink_urb(struct urb *urb)
155 It removes the urb from the internal list and frees all allocated
156 HW descriptors. The status is changed to reflect unlinking. Note
157 that the URB will not normally have finished when usb_unlink_urb()
158 returns; you must still wait for the completion handler to be called.
160 To cancel an URB synchronously, call
162 void usb_kill_urb(struct urb *urb)
164 It does everything usb_unlink_urb does, and in addition it waits
165 until after the URB has been returned and the completion handler
166 has finished. It also marks the URB as temporarily unusable, so
167 that if the completion handler or anyone else tries to resubmit it
168 they will get a -EPERM error. Thus you can be sure that when
169 usb_kill_urb() returns, the URB is totally idle.
172 1.7. What about the completion handler?
174 The handler is of the following type:
176 typedef void (*usb_complete_t)(struct urb *, struct pt_regs *)
178 I.e., it gets the URB that caused the completion call, plus the
179 register values at the time of the corresponding interrupt (if any).
180 In the completion handler, you should have a look at urb->status to
181 detect any USB errors. Since the context parameter is included in the URB,
182 you can pass information to the completion handler.
184 Note that even when an error (or unlink) is reported, data may have been
185 transferred. That's because USB transfers are packetized; it might take
186 sixteen packets to transfer your 1KByte buffer, and ten of them might
187 have transferred succesfully before the completion was called.
190 NOTE: ***** WARNING *****
191 NEVER SLEEP IN A COMPLETION HANDLER. These are normally called
192 during hardware interrupt processing. If you can, defer substantial
193 work to a tasklet (bottom half) to keep system latencies low. You'll
194 probably need to use spinlocks to protect data structures you manipulate
195 in completion handlers.
198 1.8. How to do isochronous (ISO) transfers?
200 For ISO transfers you have to fill a usb_iso_packet_descriptor structure,
201 allocated at the end of the URB by usb_alloc_urb(n,mem_flags), for each
202 packet you want to schedule. You also have to set urb->interval to say
203 how often to make transfers; it's often one per frame (which is once
204 every microframe for highspeed devices). The actual interval used will
205 be a power of two that's no bigger than what you specify.
207 The usb_submit_urb() call modifies urb->interval to the implemented interval
208 value that is less than or equal to the requested interval value. If
209 ISO_ASAP scheduling is used, urb->start_frame is also updated.
211 For each entry you have to specify the data offset for this frame (base is
212 transfer_buffer), and the length you want to write/expect to read.
213 After completion, actual_length contains the actual transferred length and
214 status contains the resulting status for the ISO transfer for this frame.
215 It is allowed to specify a varying length from frame to frame (e.g. for
216 audio synchronisation/adaptive transfer rates). You can also use the length
217 0 to omit one or more frames (striping).
219 For scheduling you can choose your own start frame or ISO_ASAP. As explained
220 earlier, if you always keep at least one URB queued and your completion
221 keeps (re)submitting a later URB, you'll get smooth ISO streaming (if usb
222 bandwidth utilization allows).
224 If you specify your own start frame, make sure it's several frames in advance
225 of the current frame. You might want this model if you're synchronizing
226 ISO data with some other event stream.
229 1.9. How to start interrupt (INT) transfers?
231 Interrupt transfers, like isochronous transfers, are periodic, and happen
232 in intervals that are powers of two (1, 2, 4 etc) units. Units are frames
233 for full and low speed devices, and microframes for high speed ones.
234 The usb_submit_urb() call modifies urb->interval to the implemented interval
235 value that is less than or equal to the requested interval value.
237 In Linux 2.6, unlike earlier versions, interrupt URBs are not automagically
238 restarted when they complete. They end when the completion handler is
239 called, just like other URBs. If you want an interrupt URB to be restarted,
240 your completion handler must resubmit it.