linux-kernel - Re: [discuss] Re: [PATCH] Allow all Opteron processors to change pstate at same time

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] [day] [month] [year] [list]

Message-Id: <200607262053.40123.ak@suse.de>
Date:	Wed, 26 Jul 2006 20:53:40 +0200
From:	Andi Kleen <ak@...e.de>
To:	discuss@...-64.org
Cc:	"Langsdorf, Mark" <mark.langsdorf@....com>,
	"Gulam, Nagib" <nagib.gulam@....com>, linux-kernel@...r.kernel.org,
	cpufreq@...ts.linux.org.uk
Subject: Re: [discuss] Re: [PATCH] Allow all Opteron processors to change pstate at same time

> In contrast, the same machine running with TSC and standard
> PN! sees massive drift, upwards of an hour, within an hour.

Do you see the same drift when you lock date on a single CPU
with taskset?

> If the TSCnow! patch reduces measured drift down to a second 
> a week, would you consider that acceptable?

No because even one second a week will break timing badly
over time. 

I believe the only good solution unless hardware helps would
be to use per CPU TSC offsets as discussed earlier. Even that
is a bit risky because there can be still very small drifts,
but they should be limited by a clock tick error max and
might work out.

-Andi

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