[PATCH] Tweak SMI sniffer commentary
From: Joe Korty
Date: Wed Apr 07 2010 - 14:56:44 EST
On Wed, Apr 07, 2010 at 02:05:07PM -0400, Randy Dunlap wrote:
> > + to detect otherwise undetectable SMIs. Not available
> > + unless CONFIG_DEBUG_SMI_SNIFFER=y.
> preferable: Only available when CONFIG_DEBUG_SMI_SNIFFER=y.
> drop "to" (redundant) ^^
> s/cpu/CPU/ throughout
> drop "to" (redundant)
> > +the applications running underneath it. For many uses this is unimportant,
> (or on top of it ;)
> > +their occurrence via the setting of a per-cpu 'system interrupt occured' flag.
Thanks! I've created a follow-on patch containing the suggested rewordings.
[PATCH] Tweak some SMI sniffer commentary
Thanks go to Randy Dunlap for these suggestions.
Signed-off-by: Joe Korty <joe.korty@xxxxxxxx>
--- 2.6.34-rc3.orig/Documentation/kernel-parameters.txt 2010-04-05 14:30:06.000000000 -0400
+++ 2.6.34-rc3/Documentation/kernel-parameters.txt 2010-04-07 14:39:50.000000000 -0400
@@ -947,8 +947,8 @@
will use a lot of power and make the system run hot.
idle=smi: variant of idle=poll that uses the spin-time
- to detect otherwise undetectable SMIs. Not available
- unless CONFIG_DEBUG_SMI_SNIFFER=y.
+ to detect otherwise undetectable SMIs. Only available
+ when CONFIG_DEBUG_SMI_SNIFFER=y.
idle=mwait: On systems which support MONITOR/MWAIT but
the kernel chose to not use it because it doesn't save
as much power as a normal idle loop, use the
--- 2.6.34-rc3.orig/Documentation/x86/smi-sniffer.txt 2010-04-05 14:30:06.000000000 -0400
+++ 2.6.34-rc3/Documentation/x86/smi-sniffer.txt 2010-04-07 14:49:19.000000000 -0400
@@ -8,17 +8,17 @@
interrupt that goes directly to the BIOS. They are used by motherboard
manufacturers to, for example, 1) simulate missing hardware in software,
such as an RTC or emulating a missing PS2 mouse/keyboard using a USB
-mouse/keyboard, 2) to perform critical motherboard duties, such as periodic
-DRAM memory refresh or slowing the cpu down whenever it gets too hot, and 3)
-to work around in software (ie, in the BIOS) deficiencies discovered after
+mouse/keyboard, 2) perform critical motherboard duties, such as periodic
+DRAM memory refresh or slowing the CPU down whenever it gets too hot, and 3)
+work around in software (i.e., in the BIOS) deficiencies discovered after
a board has been manufactured and shipped to customers.
The OS is not involved with nor even informed of these interrupts when
they occur, and indeed it is difficult for the OS to detect that they have
occurred at all. The only signature an SMI leaves behind is the time that it
-consumes. These 'time slices', taken randomly out of the running time of a cpu,
+consumes. These 'time slices', taken randomly out of the running time of a CPU,
compromise the ability of the OS to provide reasonable latency guarantees to
-the applications running underneath it. For many uses this is unimportant,
+the applications running on top of it. For many uses this is unimportant,
but for real time systems, the occurrence of an SMI during the run of some
critically-timed piece of code could shatter the correct running of the system.
@@ -36,8 +36,8 @@
routine is in use, by an "echo 1 >/proc/sys/kernel/smi_sniffer_enable" command.
The sniffer adds a pair of lines to /proc/interrupts. The "SMI" line shows
-the number of SMIs detected (per-cpu) so far. The "DSMI" line gives the
-duration, in microseconds, of the most recent SMI (for each cpu).
+the number of SMIs detected (per-CPU) so far. The "DSMI" line gives the
+duration, in microseconds, of the most recent SMI (for each CPU).
These lines appear only while the sniffer is running. If it is disabled later,
say with an "echo 0 >/proc/sys/kernel/smi_sniffer_enable", then the lines
@@ -66,7 +66,7 @@
longer than 125 usecs by the time it took to process the interrupt.
The OS is modified so that all normal system interrupts, including NMI, mark
-their occurrence via the setting of a per-cpu 'system interrupt occured' flag.
+their occurrence via the setting of a per-CPU 'system interrupt occurred' flag.
We can therefore detect SMIs by assuming that if a period significantly longer
than 125 usecs is seen, and this 'system interrupt happened' flag is not set,
that it was an SMI that lengthened the period.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/