Re: [PATCH] Tweak SMI sniffer commentary

[Randy Dunlap <randy.dunlap@oracle.com>]

On Wed, 7 Apr 2010 14:53:18 -0400 Joe Korty wrote:

> Hi Randy,
> Thanks!  I've created a follow-on patch containing the suggested rewordings.
> Joe
> 
> [PATCH] Tweak some SMI sniffer commentary
> 
> Thanks go to Randy Dunlap for these suggestions.
> 
> Signed-off-by: Joe Korty <joe.korty@ccur.com>
> 

Acked-by: Randy Dunlap <randy.dunlap@oracle.com>

Thanks.


> 
> Index: 2.6.34-rc3/Documentation/kernel-parameters.txt
> ===================================================================
> --- 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.
>  			Not recommended.
>  			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
> Index: 2.6.34-rc3/Documentation/x86/smi-sniffer.txt
> ===================================================================
> --- 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.
> --


---
~Randy