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: <20080611132921.08985eb9@infradead.org>
Date:	Wed, 11 Jun 2008 13:29:21 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	markh@...pro.net
Cc:	"linux-os (Dick Johnson)" <linux-os@...logic.com>,
	Jan Engelhardt <jengelh@...ozas.de>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	solsTiCe d'Hiver <solstice.dhiver@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: no cpu MHz in /proc/cpuinfo on 2.6.25.4-rt6

On Wed, 11 Jun 2008 13:54:33 -0400
Mark Hounschell <markh@...pro.net> wrote:

> > 
> > ondemand governor will change the cpu frequency dynamically all the
> > time.
> > the cpu itself has a dynamic range in which it operates (at least on
> > cpus that support Intel Dynamic Acceleration technology, IDA)
> > 
> 
> OK. If I am always using AMD Opteron/X64 class machines am I safe here
> when no cpu freq scaling stuff is on and I'm pinned to a particular
> processor?

today, yes. What AMD will do in the next stepping? Only they will know.

> 
> >>> 2) the rdtsc "frequency" is conceptually unrelated to cpu
> >>> frequency. In fact, you'll be hard-pressed to buy a system today
> >>> where this relationship works....
> >>>
> >> And what do you mean by "conceptually unrelated to cpu frequency"?
> >> Is it not the clock freq that is driving the cpu and the freq at
> >> which the tsc is incremented?
> > 
> > no it is not that... at all.
> > the tsc comes from an entirely different clock, and on anything you
> > can buy today from AMD or Intel (or the last year for that matter),
> > it's fixed frequency (except in idle) irrespective of the frequency
> > the CPU is operating at!
> > it's a "time stamp counter" not a "cpu cycle counter". You can run
> > instructions faster than the tsc increment or slower. Or sometimes
> > at the same rate.
> > Which it is depends on what cpufreq/ondemand are doing and how
> > active IDA is.
> > 
> 
> I was under the impression that it was the same clock on AMD Opteron
> and newer processors.

for them it's the same: it's independent of the actual cpu clock.
(and constant rate; to be constant rate you pretty much HAVE to be
independent, because you CAN do cpu frequency scaling, even if you as
user decide to not use it)
> 
> So if all this is true how and why can the kernel use it but user
> land is wrong for doing so?
> 

the kernel doesn't (really) use the frequency (other than reporting it
in /proc). And with tsc it is very very careful.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ