linux-kernel - Re: AMD X2 unsynced TSC fix?

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20061028063213.GB6357@hockin.org>
Date:	Fri, 27 Oct 2006 23:32:13 -0700
From:	thockin@...kin.org
To:	Andi Kleen <ak@...e.de>
Cc:	vojtech@...e.cz, Jiri Bohac <jbohac@...e.cz>,
	Luca Tettamanti <kronos.it@...il.com>,
	Lee Revell <rlrevell@...-job.com>,
	linux-kernel@...r.kernel.org, john stultz <johnstul@...ibm.com>
Subject: Re: AMD X2 unsynced TSC fix?

On Fri, Oct 27, 2006 at 08:59:13PM -0700, Andi Kleen wrote:
> > I fyou have a third-party clock you can get pretty darn close.
> 
> Not when powernow is involved on a multi socket system.

When CPUs are in different P-States, any resync effort will become
unsynced immediately.  I agree with that.  This is a further complication
that I think our code does not handle perfectly, yet.

> > Fortunately, we usually have an HPET, these days.  You can definitely
> > resync and get near-linear values of RDTSC.
> 
> No we don't -- most BIOS still don't give us the HPET table 
> even when it is there in hardware. In the future this will change sure
> but people will still run a lot of older motherboards.

If you know where the HPET base-address-register is, can't we program it
ourselves?  Even without HPET, we have PM Timer.  As long as you don't
need to resync the TSCs on most gtod(), you can still do better than not
trying.

> > There are few problems at hand.  I'm not familiar with the patch Andi's
> > talking about but it has to solve all these problems to be really useful:
> 
> It's from Jiri and Vojtech.  Basically it will allow to use RDTSC
> in gettimeofday even with unsynchronized TSCs by keeping
> the necessary offsets CPU local.

Offset from what?  With automatic clock ramping in C1, the rate is
cycling up and down a lot.

> > * TSC drift because of PM states, such as C1 (hlt) (semi-random, severe)
> 
> TSC drift with powernow -- CPUs run at different frequencies

Yeah, C1 is workaround-able, because the clock returns to full frequency,
and we never execute code in the reduced clock state.  Powernow makes it
more fun.  Not only do you need some offset, but you need some scalar.

Assume you resync TSCs to a clock (PM, HPET, whatever) any time any CPU
changes p-state.  Then you can calculate the approximate TSC for now by:

tsc_now = tsc_at_last_resync + ((rdtsc - tsc_at_last_resync) * pstate_scalar)

Something like that.  Not pretty, but still possible to get close.  And
close might be good enough.  As long as you can guarantee monotonicity and
approximate linearity, you can make most apps happy ENOUGH.

Tim
-
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/