Dave Johnson wrote:
> From: Dave Johnson <[email protected]>
>
> The previous patch wasn't correctly handling the 'count' variable. If
> a CPU gave bad results on the 1st or 2nd run but good results on the
> 3rd, it wouldn't do the correct thing. No idea if any such CPU
> exists, but the patch below handles that case by discarding the bad
> runs.
>
> If a bad result (too quick, or too slow) occurs on any of the 3 runs
> it will be discarded.
>
> Also updated some comments to explain what's going on.
>
> Signed-off-by: Dave Johnson <[email protected]>
>
> ---
>
> Should be applied after my previous patch.
>
> ===== arch/i386/kernel/tsc.c 1.28 vs edited =====
> --- 1.28/arch/i386/kernel/tsc.c 2007-10-19 11:07:36 -04:00
> +++ edited/arch/i386/kernel/tsc.c 2007-10-19 11:07:44 -04:00
> @@ -128,29 +128,35 @@
>
> local_irq_save(flags);
>
> - /* run 3 times to ensure the cache is warm */
> + /* run 3 times to ensure the cache is warm and to get an accurate reading */
> for (i = 0; i < 3; i++) {
> mach_prepare_counter();
It's a really rare case, but if SMI interrupt takes CPU here, just after
prepare and before rdtscll, it makes delta64 shorter than expected one.
Is it possible? And how about moving rdtscll before mach_prepare_counter()?
> rdtscll(start);
Thanks
Hiroshi Shimamoto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
