linux-kernel - Re: nosmp/maxcpus=0 or 1 -> TSC unstable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Jan 2008 17:50:39 -0500
From:	Pete Wyckoff <pw@....edu>
To:	dean gaudet <dean@...tic.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: nosmp/maxcpus=0 or 1 -> TSC unstable

dean@...tic.org wrote on Sat, 12 Jan 2008 11:48 -0800:
> if i boot an x86 64-bit 2.6.24-rc7 kernel with nosmp, maxcpus=0 or 1 it 
> still disables TSC :)
> 
> Marking TSC unstable due to TSCs unsynchronized
> 
> this is an opteron 2xx box which does have two cpus and no clock-divide in 
> halt or cpufreq enabled so TSC should be fine with only one cpu.
> 
> pretty sure this is the culprit is that num_possible_cpus() > 1, which 
> would mean cpu_possible_map contains the second cpu... but i'm not quite 
> sure what the right fix is... or perhaps this is all intended.

We've seen the same problem.  We use gettimeofday() for timing of
network-ish operations on the order of 10-50 us.  But not having
the TSC makes gettimeofday() itself very slow, on the order of 30 us.

Here's what we've been using for quite a few kernel versions.  I've
not tried to submit it for fear that it could break some other
scenario, as you suggest.  Although in hotplug scenarios, this
function unsynchronized_tsc() should get rerun and disable TSC if
more processors arrive.

At least count this as a "me too".

		-- Pete

>From 0cdcd494bc0e27f49438bc2fc72fd3823629802b Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <pw@....edu>
Date: Tue, 15 Jan 2008 17:42:28 -0500
Subject: [PATCH] use tsc on 1 cpu smp

Use num_online_cpus() instead of num_present_cpus() as the
parameter to check when deciding if TSC is good enough.  Thus
explicitly booting with maxcpus=1 will let us use the TSC even on
a dual-processor machine.  This helps reduce gettimeofday
overheads on our dual Opteron nodes immensely (30 us vs 0.5 us).

Signed-off-by: Pete Wyckoff <pw@....edu>
---
 arch/x86/kernel/tsc_64.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/tsc_64.c b/arch/x86/kernel/tsc_64.c
index 9c70af4..5f2e91f 100644
--- a/arch/x86/kernel/tsc_64.c
+++ b/arch/x86/kernel/tsc_64.c
@@ -235,7 +235,7 @@ __cpuinit int unsynchronized_tsc(void)
 	}

 	/* Assume multi socket systems are not synchronized */
-	return num_present_cpus() > 1;
+	return num_online_cpus() > 1;
 }

 int __init notsc_setup(char *s)
-- 
1.5.3.7

--
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/