Messages in this thread | | | Date | Sat, 27 Sep 2008 18:51:07 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86: TSC resync |
| |
* 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
| |