All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.