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

On Tuesday 17 September 2002 05:05 pm, Andi Kleen wrote:
> On Tue, Sep 17, 2002 at 04:51:31PM -0700, David S. Miller wrote:
> >    From: Andi Kleen <ak@suse.de>
> >    Date: Wed, 18 Sep 2002 01:58:38 +0200
> >
> >    The local APIC timer is specified in the Intel Manual volume 3 for
> > example. It's an optional feature (CPUID), but pretty much everyone has
> > it.
> >
> > It is internal or external to the processor?  Ie. can it be in the
> > southbridge or something?  If yes, then I still hold my point.
>
> Local Apic is in the cpu.
>
> -Andi

I believe you gents are going off at a tangent.  Intel's current P4 manual 
says the local APIC timer is driven by the "bus clock".  For serial APICs 
that was doubtless the APIC serial bus clock, which almost always was derived 
from the system clock.  For P4 systems with the xAPIC in parallel mode, the 
only one available is the system bus.

If a multi-node system doesn't have synchronized bus clocks, it doesn't matter 
which one you use.  The time bases will drift relative to each other.

It's even worse when the "Frequency Spreading" BIOS option is turned on.  
Then, the bus clocks are deliberately offset by as much as half a megahertz 
(doubtless to pass FCC or equivalent emission certifications).

I don't know what Sun does with the Ultra SPARC 3's time counter.  Maybe they 
have a separate clock input for it that runs at 1 MHz so skew and 
distribution is no problem.  That's fine for Sun; they build their own CPUs 
and can put in whatever they want.  The rest of us have to work with what we 
get from the different manufacturers.  And, just about all of them use a 
value derived from the bus clock -- which might have drift in a multi-node 
system.

That's where a better abstraction of the timer hardware would come in handy.  
It would use the PIT or TSC for 99% of boxes, and switch to special code for 
the weird ones.

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


  reply	other threads:[~2002-09-18  1:00 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
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 [this message]
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=200209171804.33391.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