From: Andi Kleen <andi@firstfloor.org>
To: Guillaume Chazarain <guichaz@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
Karsten Wiese <fzu@wemgehoertderstaat.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now
Date: Fri, 11 Apr 2008 10:40:29 +0200 [thread overview]
Message-ID: <20080411084029.GT10019@one.firstfloor.org> (raw)
In-Reply-To: <3d8471ca0804110125r1b4e97c0ua419587a64c9b1c7@mail.gmail.com>
On Fri, Apr 11, 2008 at 10:25:09AM +0200, Guillaume Chazarain wrote:
> On Fri, Apr 11, 2008 at 10:06 AM, Andi Kleen <andi@firstfloor.org> wrote:
> > At some point you have to generate an offset to something and that
> > offset must be different for different frequencies, otherwise
> > you get large systematic errors
>
> This offset is already there, represented by rq->clock - sched_clock()
Same issue. Think about it. Perhaps I should have written
the complicated proof :)
You really have to compute the offset before the scaling, otherwise it
is useless.
TSC is a counter that adds up time units. Now when the frequency
changes the time units change, but counter doesn't reset.
Now the full absolue value of the counter is useless for exact time
because there is no way to reconstruct what the lengths of the different
time units meshed together in the single counter value were
and how long it ticked at the different frequencies.
So after a frequency change the only way to get anything
approaching a sane time is to take a snapshot of the counter
already ticking at the new frequency (but before it is scaled!)
and then only work with current TSC - snapshot and only scale
after that.
Then there is also the issue that you don't know when exactly
the counter changes and any measurements during that time
might be dodgy (but system is not usually fully stopped during
it).
The rewritten sched_clock handled this by having a unstable period
between cpufreq starting to change, cpufreq reporting end of change
and falling back to another clock during this instable period.
Also there are of course other users, like printk who
don't have rq->clock.
-Andi
prev parent reply other threads:[~2008-04-11 8:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-10 21:31 [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now Karsten Wiese
2008-04-11 7:42 ` Andi Kleen
2008-04-11 7:55 ` Ingo Molnar
2008-04-11 8:06 ` Andi Kleen
2008-04-11 8:25 ` Guillaume Chazarain
2008-04-11 8:40 ` Andi Kleen [this message]
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=20080411084029.GT10019@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=fzu@wemgehoertderstaat.de \
--cc=guichaz@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.