Messages in this thread | | | Date | Wed, 7 Apr 2010 12:00:30 -0700 | From | Randy Dunlap <> | Subject | Re: [PATCH] Tweak SMI sniffer commentary |
| |
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
| |