view Documentation/block/request.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
2 struct request documentation
4 Jens Axboe <axboe@suse.de> 27/05/02
6 1.0
7 Index
9 2.0 Struct request members classification
11 2.1 struct request members explanation
13 3.0
16 2.0
17 Short explanation of request members
19 Classification flags:
21 D driver member
22 B block layer member
23 I I/O scheduler member
25 Unless an entry contains a D classification, a device driver must not access
26 this member. Some members may contain D classifications, but should only be
27 access through certain macros or functions (eg ->flags).
29 <linux/blkdev.h>
31 2.1
32 Member Flag Comment
33 ------ ---- -------
35 struct list_head queuelist BI Organization on various internal
36 queues
38 void *elevator_private I I/O scheduler private data
40 unsigned char cmd[16] D Driver can use this for setting up
41 a cdb before execution, see
42 blk_queue_prep_rq
44 unsigned long flags DBI Contains info about data direction,
45 request type, etc.
47 int rq_status D Request status bits
49 kdev_t rq_dev DBI Target device
51 int errors DB Error counts
53 sector_t sector DBI Target location
55 unsigned long hard_nr_sectors B Used to keep sector sane
57 unsigned long nr_sectors DBI Total number of sectors in request
59 unsigned long hard_nr_sectors B Used to keep nr_sectors sane
61 unsigned short nr_phys_segments DB Number of physical scatter gather
62 segments in a request
64 unsigned short nr_hw_segments DB Number of hardware scatter gather
65 segments in a request
67 unsigned int current_nr_sectors DB Number of sectors in first segment
68 of request
70 unsigned int hard_cur_sectors B Used to keep current_nr_sectors sane
72 int tag DB TCQ tag, if assigned
74 void *special D Free to be used by driver
76 char *buffer D Map of first segment, also see
77 section on bouncing SECTION
79 struct completion *waiting D Can be used by driver to get signalled
80 on request completion
82 struct bio *bio DBI First bio in request
84 struct bio *biotail DBI Last bio in request
86 request_queue_t *q DB Request queue this request belongs to
88 struct request_list *rl B Request list this request came from