ia64/linux-2.6.18-xen.hg

view Documentation/block/stat.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
children
line source
1 Block layer statistics in /sys/block/<dev>/stat
2 ===============================================
4 This file documents the contents of the /sys/block/<dev>/stat file.
6 The stat file provides several statistics about the state of block
7 device <dev>.
9 Q. Why are there multiple statistics in a single file? Doesn't sysfs
10 normally contain a single value per file?
11 A. By having a single file, the kernel can guarantee that the statistics
12 represent a consistent snapshot of the state of the device. If the
13 statistics were exported as multiple files containing one statistic
14 each, it would be impossible to guarantee that a set of readings
15 represent a single point in time.
17 The stat file consists of a single line of text containing 11 decimal
18 values separated by whitespace. The fields are summarized in the
19 following table, and described in more detail below.
21 Name units description
22 ---- ----- -----------
23 read I/Os requests number of read I/Os processed
24 read merges requests number of read I/Os merged with in-queue I/O
25 read sectors sectors number of sectors read
26 read ticks milliseconds total wait time for read requests
27 write I/Os requests number of write I/Os processed
28 write merges requests number of write I/Os merged with in-queue I/O
29 write sectors sectors number of sectors written
30 write ticks milliseconds total wait time for write requests
31 in_flight requests number of I/Os currently in flight
32 io_ticks milliseconds total time this block device has been active
33 time_in_queue milliseconds total wait time for all requests
35 read I/Os, write I/Os
36 =====================
38 These values increment when an I/O request completes.
40 read merges, write merges
41 =========================
43 These values increment when an I/O request is merged with an
44 already-queued I/O request.
46 read sectors, write sectors
47 ===========================
49 These values count the number of sectors read from or written to this
50 block device. The "sectors" in question are the standard UNIX 512-byte
51 sectors, not any device- or filesystem-specific block size. The
52 counters are incremented when the I/O completes.
54 read ticks, write ticks
55 =======================
57 These values count the number of milliseconds that I/O requests have
58 waited on this block device. If there are multiple I/O requests waiting,
59 these values will increase at a rate greater than 1000/second; for
60 example, if 60 read requests wait for an average of 30 ms, the read_ticks
61 field will increase by 60*30 = 1800.
63 in_flight
64 =========
66 This value counts the number of I/O requests that have been issued to
67 the device driver but have not yet completed. It does not include I/O
68 requests that are in the queue but not yet issued to the device driver.
70 io_ticks
71 ========
73 This value counts the number of milliseconds during which the device has
74 had I/O requests queued.
76 time_in_queue
77 =============
79 This value counts the number of milliseconds that I/O requests have waited
80 on this block device. If there are multiple I/O requests waiting, this
81 value will increase as the product of the number of milliseconds times the
82 number of requests waiting (see "read ticks" above for an example).