From: Ingo Molnar <mingo@elte.hu>
To: Michael Davidson <md@google.com>
Cc: linux-kernel@vger.kernel.org, mbligh@google.com,
tglx@linutronix.de, Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linus Torvalds <torvalds@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86: TSC resync
Date: Sat, 27 Sep 2008 18:51:07 +0200 [thread overview]
Message-ID: <20080927165107.GF4600@elte.hu> (raw)
In-Reply-To: <6cc912950809261218u5a1bf8b8w216556b50d0e33ab@mail.gmail.com>
* Michael Davidson <md@google.com> wrote:
> On Fri, Sep 26, 2008 at 12:02 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> > hm, this patch syncs the TSCs every 20 seconds. That is enough to
> > sync up AMD CPUs where the TSC slows down _slightly_ (at 10 ppm per
> > second or so) when it's in HLT.
>
> Actually by default it syncs them every time the CPU comes out of idle
> or, optionally, on the first user space access to the TSC via RDTSC or
> RDTSCP after the CPU has been in idle.
hm, that would be a performance problem.
coming out of idle is a fastpath: the CPU just got notified of more
work, so any delay there costs.
[ going _to_ idle is more relaxed from a performance POV - but that
doesnt help much here. ]
and the default_idle()->tsc_resync_idle_notifier()->tsc_resync()->
ref_clock_tsc_read()->ref_clock() codepath does this:
+ offset = (uint32_t)hpet_readl(HPET_COUNTER) - ref_clock_last;
i.e. we read the HPET every time we exit from idle. The HPET usually
sits in the southbridge and thus we add ~5000 cycles of overhead to
every idle-exit event.
Another thing i noticed. You set the TSC via the 0x10 MSR:
+ asm __volatile__ (
+ "xorl %%eax, %%eax\n\t"
+ "cpuid\n\t"
+ "movl $0x10, %%ecx\n\t"
+ "rdmsr\n\t"
+ "addl %%edi, %%eax\n\t"
+ "adcl %%esi, %%edx\n\t"
+ "wrmsr\n"
some CPUs (P3's?) will crop the TSC at 32 bits when wrtsc is used [even
if a larger than 0xfffffffff value is presented in ax/dx. - i.e. the TSC
will go round and round, with a rollover every few seconds.
those CPUs would have to be detected and excluded from this scheme.
Ingo
prev parent reply other threads:[~2008-09-27 16:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-25 22:02 [PATCH] x86: TSC resync Michael Davidson
2008-09-26 7:02 ` Ingo Molnar
[not found] ` <6cc912950809261218u5a1bf8b8w216556b50d0e33ab@mail.gmail.com>
2008-09-27 16:51 ` Ingo Molnar [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=20080927165107.GF4600@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=md@google.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 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.