[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100407120030.26d53073.randy.dunlap@oracle.com>
Date: Wed, 7 Apr 2010 12:00:30 -0700
From: Randy Dunlap <randy.dunlap@...cle.com>
To: Joe Korty <joe.korty@...r.com>
Cc: Ingo Molnar <mingo@...e.hu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
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@...r.com>
>
Acked-by: Randy Dunlap <randy.dunlap@...cle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists