ia64/linux-2.6.18-xen.hg

view Documentation/sh/kgdb.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
2 This file describes the configuration and behavior of KGDB for the SH
3 kernel. Based on a description from Henry Bell <henry.bell@st.com>, it
4 has been modified to account for quirks in the current implementation.
6 Version
7 =======
9 This version of KGDB was written for 2.4.xx kernels for the SH architecture.
10 Further documentation is available from the linux-sh project website.
13 Debugging Setup: Host
14 ======================
16 The two machines will be connected together via a serial line - this
17 should be a null modem cable i.e. with a twist.
19 On your DEVELOPMENT machine, go to your kernel source directory and
20 build the kernel, enabling KGDB support in the "kernel hacking" section.
21 This includes the KGDB code, and also makes the kernel be compiled with
22 the "-g" option set -- necessary for debugging.
24 To install this new kernel, use the following installation procedure.
26 Decide on which tty port you want the machines to communicate, then
27 cable them up back-to-back using the null modem. On the DEVELOPMENT
28 machine, you may wish to create an initialization file called .gdbinit
29 (in the kernel source directory or in your home directory) to execute
30 commonly-used commands at startup.
32 A minimal .gdbinit might look like this:
34 file vmlinux
35 set remotebaud 115200
36 target remote /dev/ttyS0
38 Change the "target" definition so that it specifies the tty port that
39 you intend to use. Change the "remotebaud" definition to match the
40 data rate that you are going to use for the com line (115200 is the
41 default).
43 Debugging Setup: Target
44 ========================
46 By default, the KGDB stub will communicate with the host GDB using
47 ttySC1 at 115200 baud, 8 databits, no parity; these defaults can be
48 changed in the kernel configuration. As the kernel starts up, KGDB will
49 initialize so that breakpoints, kernel segfaults, and so forth will
50 generally enter the debugger.
52 This behavior can be modified by including the "kgdb" option in the
53 kernel command line; this option has the general form:
55 kgdb=<ttyspec>,<action>
57 The <ttyspec> indicates the port to use, and can optionally specify
58 baud, parity and databits -- e.g. "ttySC0,9600N8" or "ttySC1,19200".
60 The <action> can be "halt" or "disabled". The "halt" action enters the
61 debugger via a breakpoint as soon as kgdb is initialized; the "disabled"
62 action causes kgdb to ignore kernel segfaults and such until explicitly
63 entered by a breakpoint in the code or by external action (sysrq or NMI).
65 (Both <ttyspec> and <action> can appear alone, w/o the separating comma.)
67 For example, if you wish to debug early in kernel startup code, you
68 might specify the halt option:
70 kgdb=halt
72 Boot the TARGET machinem, which will appear to hang.
74 On your DEVELOPMENT machine, cd to the source directory and run the gdb
75 program. (This is likely to be a cross GDB which runs on your host but
76 is built for an SH target.) If everything is working correctly you
77 should see gdb print out a few lines indicating that a breakpoint has
78 been taken. It will actually show a line of code in the target kernel
79 inside the gdbstub activation code.
81 NOTE: BE SURE TO TERMINATE OR SUSPEND any other host application which
82 may be using the same serial port (for example, a terminal emulator you
83 have been using to connect to the target boot code.) Otherwise, data
84 from the target may not all get to GDB!
86 You can now use whatever gdb commands you like to set breakpoints.
87 Enter "continue" to start your target machine executing again. At this
88 point the target system will run at full speed until it encounters
89 your breakpoint or gets a segment violation in the kernel, or whatever.
91 Serial Ports: KGDB, Console
92 ============================
94 This version of KGDB may not gracefully handle conflict with other
95 drivers in the kernel using the same port. If KGDB is configured on the
96 same port (and with the same parameters) as the kernel console, or if
97 CONFIG_SH_KGDB_CONSOLE is configured, things should be fine (though in
98 some cases console messages may appear twice through GDB). But if the
99 KGDB port is not the kernel console and used by another serial driver
100 which assumes different serial parameters (e.g. baud rate) KGDB may not
101 recover.
103 Also, when KGDB is entered via sysrq-g (requires CONFIG_KGDB_SYSRQ) and
104 the kgdb port uses the same port as the console, detaching GDB will not
105 restore the console to working order without the port being re-opened.
107 Another serious consequence of this is that GDB currently CANNOT break
108 into KGDB externally (e.g. via ^C or <BREAK>); unless a breakpoint or
109 error is encountered, the only way to enter KGDB after the initial halt
110 (see above) is via NMI (CONFIG_KGDB_NMI) or sysrq-g (CONFIG_KGDB_SYSRQ).
112 Code is included for the basic Hitachi Solution Engine boards to allow
113 the use of ttyS0 for KGDB if desired; this is less robust, but may be
114 useful in some cases. (This cannot be selected using the config file,
115 but only through the kernel command line, e.g. "kgdb=ttyS0", though the
116 configured defaults for baud rate etc. still apply if not overridden.)
118 If gdbstub Does Not Work
119 ========================
121 If it doesn't work, you will have to troubleshoot it. Do the easy
122 things first like double checking your cabling and data rates. You
123 might try some non-kernel based programs to see if the back-to-back
124 connection works properly. Just something simple like cat /etc/hosts
125 /dev/ttyS0 on one machine and cat /dev/ttyS0 on the other will tell you
126 if you can send data from one machine to the other. There is no point
127 in tearing out your hair in the kernel if the line doesn't work.
129 If you need to debug the GDB/KGDB communication itself, the gdb commands
130 "set debug remote 1" and "set debug serial 1" may be useful, but be
131 warned: they produce a lot of output.
133 Threads
134 =======
136 Each process in a target machine is seen as a gdb thread. gdb thread related
137 commands (info threads, thread n) can be used. CONFIG_KGDB_THREAD must
138 be defined for this to work.
140 In this version, kgdb reports PID_MAX (32768) as the process ID for the
141 idle process (pid 0), since GDB does not accept 0 as an ID.
143 Detaching (exiting KGDB)
144 =========================
146 There are two ways to resume full-speed target execution: "continue" and
147 "detach". With "continue", GDB inserts any specified breakpoints in the
148 target code and resumes execution; the target is still in "gdb mode".
149 If a breakpoint or other debug event (e.g. NMI) happens, the target
150 halts and communicates with GDB again, which is waiting for it.
152 With "detach", GDB does *not* insert any breakpoints; target execution
153 is resumed and GDB stops communicating (does not wait for the target).
154 In this case, the target is no longer in "gdb mode" -- for example,
155 console messages no longer get sent separately to the KGDB port, or
156 encapsulated for GDB. If a debug event (e.g. NMI) occurs, the target
157 will re-enter "gdb mode" and will display this fact on the console; you
158 must give a new "target remote" command to gdb.
160 NOTE: TO AVOID LOSSING CONSOLE MESSAGES IN CASE THE KERNEL CONSOLE AND
161 KGDB USING THE SAME PORT, THE TARGET WAITS FOR ANY INPUT CHARACTER ON
162 THE KGDB PORT AFTER A DETACH COMMAND. For example, after the detach you
163 could start a terminal emulator on the same host port and enter a <cr>;
164 however, this program must then be terminated or suspended in order to
165 use GBD again if KGDB is re-entered.
168 Acknowledgements
169 ================
171 This code was mostly generated by Henry Bell <henry.bell@st.com>;
172 largely from KGDB by Amit S. Kale <akale@veritas.com> - extracts from
173 code by Glenn Engel, Jim Kingdon, David Grothe <dave@gcom.com>, Tigran
174 Aivazian <tigran@sco.com>, William Gatliff <bgat@open-widgets.com>, Ben
175 Lee, Steve Chamberlain and Benoit Miller <fulg@iname.com> are also
176 included.
178 Jeremy Siegel
179 <jsiegel@mvista.com>