From: Andi Kleen <ak@suse.de>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Dave Jones <davej@redhat.com>, Andi Kleen <ak@suse.de>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Andrew Morton <akpm@osdl.org>, cpufreq <cpufreq@www.linux.org.uk>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] CPU frequency display in /proc/cpuinfo
Date: Mon, 5 Dec 2005 19:36:54 +0100 [thread overview]
Message-ID: <20051205183654.GG11190@wotan.suse.de> (raw)
In-Reply-To: <1133796748.21641.8.camel@mindpipe>
> JACK needs to know the CPU speed in order to be able to use RDTSC for
> timing. Yes that might be "broken" but gettimeofday() is simply not
It is broken then. Was always broken, will be broken etc.
> fast enough for our use, we can't afford the overhead of thousands of
> system calls per second. And until recently 99.999% of desktop machines
> had a monotonic TSC so this worked very well.
You're wrong. First if you say "monotonic" you don't understand the problem.
Monotonicity is only a small part of it. The bigger one is just
getting the current frequency and figuring out of if the information
is safe to use.
Chips where it doesn't work:
- Intel Prescott and derivatives (newer Pentium 4, newer Xeon, on
Celeron you are still lucky because they normally don't have speedstep):
TSC runs at a different frequency than the current P state and P state often
varies with speedstep [These are the most common desktop chips in the world,
although not all have speedstep enabled. Many newer ones have though.]
- Intel P-M and earlier P4,P3 mobile chips, Athlon 64, Athlon XP-M,
Opteron etc:
TSC varies with P state and user space has no way to get timely
updates on P-state changes.
- VIA C3: I believe TSC stops in idle (at least it used to on
older versions, don't know if they fixed it)
-Andi
next prev parent reply other threads:[~2005-12-05 18:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-02 18:13 Venkatesh Pallipadi
2005-12-02 18:19 ` Andi Kleen
2005-12-02 18:43 ` Venkatesh Pallipadi
2005-12-04 16:43 ` Dominik Brodowski
2005-12-04 18:32 ` Andi Kleen
2005-12-04 19:49 ` Lee Revell
2005-12-04 20:13 ` Andi Kleen
2005-12-04 21:01 ` Horst von Brand
2005-12-05 1:16 ` Dave Jones
2005-12-05 13:02 ` Erik Mouw
2005-12-05 17:25 ` Dave Jones
2005-12-05 17:27 ` Lee Revell
2005-12-06 11:13 ` Erik Mouw
2005-12-06 16:56 ` Dave Jones
2005-12-06 17:35 ` Erik Mouw
2005-12-05 15:32 ` Lee Revell
2005-12-05 18:36 ` Andi Kleen [this message]
2005-12-05 15:59 ` Mark Lord
2005-12-05 17:26 ` Dave Jones
2005-12-05 16:29 ` Avi Kivity
2005-12-05 16:46 ` linux-os (Dick Johnson)
2005-12-05 17:27 ` Dave Jones
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=20051205183654.GG11190@wotan.suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=cpufreq@www.linux.org.uk \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=venkatesh.pallipadi@intel.com \
/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
all inboxes | Powered by JetHome®