view Documentation/cpu-freq/core.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 CPU frequency and voltage scaling code in the Linux(TM) kernel
4 L i n u x C P U F r e q
6 C P U F r e q C o r e
9 Dominik Brodowski <linux@brodo.de>
10 David Kimdon <dwhedon@debian.org>
14 Clock scaling allows you to change the clock speed of the CPUs on the
15 fly. This is a nice method to save battery power, because the lower
16 the clock speed, the less power the CPU consumes.
19 Contents:
20 ---------
21 1. CPUFreq core and interfaces
22 2. CPUFreq notifiers
24 1. General Information
25 =======================
27 The CPUFreq core code is located in linux/kernel/cpufreq.c. This
28 cpufreq code offers a standardized interface for the CPUFreq
29 architecture drivers (those pieces of code that do actual
30 frequency transitions), as well as to "notifiers". These are device
31 drivers or other part of the kernel that need to be informed of
32 policy changes (ex. thermal modules like ACPI) or of all
33 frequency changes (ex. timing code) or even need to force certain
34 speed limits (like LCD drivers on ARM architecture). Additionally, the
35 kernel "constant" loops_per_jiffy is updated on frequency changes
36 here.
38 Reference counting is done by cpufreq_get_cpu and cpufreq_put_cpu,
39 which make sure that the cpufreq processor driver is correctly
40 registered with the core, and will not be unloaded until
41 cpufreq_put_cpu is called.
43 2. CPUFreq notifiers
44 ====================
46 CPUFreq notifiers conform to the standard kernel notifier interface.
47 See linux/include/linux/notifier.h for details on notifiers.
49 There are two different CPUFreq notifiers - policy notifiers and
50 transition notifiers.
53 2.1 CPUFreq policy notifiers
54 ----------------------------
56 These are notified when a new policy is intended to be set. Each
57 CPUFreq policy notifier is called three times for a policy transition:
59 1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
60 they see a need for this - may it be thermal considerations or
61 hardware limitations.
63 2.) During CPUFREQ_INCOMPATIBLE only changes may be done in order to avoid
64 hardware failure.
66 3.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
67 - if two hardware drivers failed to agree on a new policy before this
68 stage, the incompatible hardware shall be shut down, and the user
69 informed of this.
71 The phase is specified in the second argument to the notifier.
73 The third argument, a void *pointer, points to a struct cpufreq_policy
74 consisting of five values: cpu, min, max, policy and max_cpu_freq. min
75 and max are the lower and upper frequencies (in kHz) of the new
76 policy, policy the new policy, cpu the number of the affected CPU; and
77 max_cpu_freq the maximum supported CPU frequency. This value is given
78 for informational purposes only.
81 2.2 CPUFreq transition notifiers
82 --------------------------------
84 These are notified twice when the CPUfreq driver switches the CPU core
85 frequency and this change has any external implications.
87 The second argument specifies the phase - CPUFREQ_PRECHANGE or
90 The third argument is a struct cpufreq_freqs with the following
91 values:
92 cpu - number of the affected CPU
93 old - old frequency
94 new - new frequency
96 If the cpufreq core detects the frequency has changed while the system
97 was suspended, these notifiers are called with CPUFREQ_RESUMECHANGE as
98 second argument.