All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Wyckoff <pw@osc.edu>
To: dean gaudet <dean@arctic.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: nosmp/maxcpus=0 or 1 -> TSC unstable
Date: Tue, 15 Jan 2008 17:50:39 -0500	[thread overview]
Message-ID: <20080115225039.GA25701@osc.edu> (raw)
In-Reply-To: <alpine.DEB.0.999999.0801121142370.11727@twinlark.arctic.org>

dean@arctic.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@osc.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@osc.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


  reply	other threads:[~2008-01-15 22:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-12 19:48 nosmp/maxcpus=0 or 1 -> TSC unstable dean gaudet
2008-01-15 22:50 ` Pete Wyckoff [this message]
2008-01-16  4:13   ` Andi Kleen
2008-01-16 15:31   ` Ingo Molnar
2008-01-16 16:24     ` Pete Wyckoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080115225039.GA25701@osc.edu \
    --to=pw@osc.edu \
    --cc=dean@arctic.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.