public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Cleverdon <jamesclv@us.ibm.com>
To: "David S. Miller" <davem@redhat.com>, alan@lxorguk.ukuu.org.uk
Cc: ak@suse.de, linux-kernel@vger.kernel.org, johnstul@us.ibm.com,
	anton.wilson@camotion.com
Subject: Re: do_gettimeofday vs. rdtsc in the scheduler
Date: Tue, 17 Sep 2002 15:02:04 -0700	[thread overview]
Message-ID: <200209171502.04524.jamesclv@us.ibm.com> (raw)
In-Reply-To: <20020917.141806.49377410.davem@redhat.com>

On Tuesday 17 September 2002 02:18 pm, David S. Miller wrote:
>    From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>    Date: 17 Sep 2002 22:28:12 +0100
>
>    A bus clock - but things like the x440 have more than one bus clock. Its
>    NUMA. Also the bus clock and rdtsc clock are different - rdtsc is
>    dependant on the multiplier. Shove a celeron 300 and a celeron 450 in a
>    BP6 board with tsc on and enjoy
>
> That's mostly my point.
>
> If the bus clocks differ, then great create some system wide crystal
> oscillator.  That's a detail, the important bit is that you don't need
> to go out to the system bus to read the tick value, it must be cpu
> local to be effective and without serious performance impact.
> -

It's more than just a detail.  Sequent's last NUMA system (_not_ the NUMA-Q;  
never released) did exactly what you suggest.  The midplane card generated 
the bus clock for all quad modules.  We had requested this feature because it 
was such a pain dealing with clock drift between nodes in the OS.

The HW guys were able to give us synchronized bus clocks on a 16-way box, but 
warned us that it would not be practical on the 256-way.  Too much clock skew 
at those speeds, or something like that.  I suppose you could trade off 
interconnect rate for clock sync, but then performance would suffer.

I don't know how Sun and SGI manage with their larger systems.  Either they 
don't do clock sync, or they may have to make expensive tradeoffs.

Interestingly, Intel's IA64 manual does not guarantee that the CPU clock (and 
thus its TSC register) has anything to do with the bus clock rate.  Maybe 
they want to dabble with asynchronous logic or multiple clock domains in 
future CPUs.

Trivia:  NUMA-Q systems running Dynix/PTX can contain quads running at very 
different CPU speeds.  This made locating some race conditions quite easy.

-- 
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com


  reply	other threads:[~2002-09-17 21:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200209172020.g8HKKPF13227@eng2.beaverton.ibm.com.suse.lists.linux.kernel>
     [not found] ` <1032294559.22815.180.camel@cog.suse.lists.linux.kernel>
     [not found]   ` <20020917.133933.69057655.davem@redhat.com.suse.lists.linux.kernel>
2002-09-17 21:00     ` do_gettimeofday vs. rdtsc in the scheduler Andi Kleen
2002-09-17 20:54       ` David S. Miller
2002-09-17 21:28         ` Alan Cox
2002-09-17 21:18           ` David S. Miller
2002-09-17 22:02             ` James Cleverdon [this message]
2002-09-17 22:44               ` Andi Kleen
2002-09-17 22:38                 ` David S. Miller
2002-09-17 22:55                   ` James Cleverdon
2002-09-17 23:12                     ` David S. Miller
2002-09-17 23:32                       ` john stultz
2002-09-17 23:32                         ` David S. Miller
2002-09-17 23:52                           ` Andi Kleen
2002-09-17 23:46                             ` David S. Miller
2002-09-17 23:58                               ` Andi Kleen
2002-09-17 23:51                                 ` David S. Miller
2002-09-18  0:05                                   ` Andi Kleen
2002-09-18  1:04                                     ` James Cleverdon
2002-09-19 18:02                                       ` Andrea Arcangeli
2002-09-20 11:04                                     ` Maciej W. Rozycki
2002-09-19 11:20                                 ` Mikael Pettersson
2002-09-19 13:27                                   ` Alan Cox
2002-09-19 13:39                                     ` Mikael Pettersson
2002-09-20 15:26                                     ` John Levon
2002-09-18  6:40               ` Vojtech Pavlik
2002-09-19 18:04                 ` Andrea Arcangeli
     [not found] <200209172020.g8HKKPF13227@eng2.beaverton.ibm.com>
2002-09-17 20:29 ` Fwd: " john stultz
2002-09-17 20:39   ` David S. Miller
2002-09-17 20:57     ` john stultz
2002-09-17 20:56       ` David S. Miller
2002-09-09 22:21 anton wilson

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=200209171502.04524.jamesclv@us.ibm.com \
    --to=jamesclv@us.ibm.com \
    --cc=ak@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anton.wilson@camotion.com \
    --cc=davem@redhat.com \
    --cc=johnstul@us.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox