linux-kernel - Re: [PATCH] x86: TSC resync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20080927165107.GF4600@elte.hu>
Date:	Sat, 27 Sep 2008 18:51:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Michael Davidson <md@...gle.com>
Cc:	linux-kernel@...r.kernel.org, mbligh@...gle.com,
	tglx@...utronix.de, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86: TSC resync


* Michael Davidson <md@...gle.com> wrote:

> On Fri, Sep 26, 2008 at 12:02 AM, Ingo Molnar <mingo@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/