linux-kernel - Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

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

Date:	Thu, 16 Jun 2016 16:44:20 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Huang Rui <ray.huang@....com>
cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	Borislav Petkov <bp@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Robert Richter <rric@...nel.org>,
	Jacob Shin <jacob.w.shin@...il.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Kan Liang <kan.liang@...el.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org,
	Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com>,
	Borislav Petkov <bp@...en8.de>,
	Guenter Roeck <linux@...ck-us.net>,
	Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [REDO PATCH v7] perf/x86/amd/power: Add AMD accumulated power
 reporting mechanism

On Thu, 16 Jun 2016, Huang Rui wrote:

> > 1.  In theory this should also work on an amd fam16h model 30h
> >     processor too, correct?  The current code limits things to fam15h
> >     even though the fam16mod30h has all the proper cpuid flags.
> > 
> 
> I was told this feature would be supported on fam15h 60h, 70h and
> later processors before. Just checked the fam16h model 30h BKDG, yes,
> it should be also supported. But I didn't test that platform, if you
> confirm it works in your side. We can enable it.

I can confirm I get power readings on my fam16hmod30h board once I apply a 
trivial patch to the driver.  I'll send the patch in a separate e-mail.

> PTSC's frequency is about 100Mhz, it shouldn't be overflow.

That's what I thought.  I'm trying to read the value using the /dev/msr 
interface from userspace and I get weird results.

i.e.:
	Jx: read 62d299b84
	PTSC MSR: read 72fe92
	
	sleep 5ms

	Jy: read 631b453b9
	PTSC MSR: read 46b25

this happens about half the time (PTSC going backwards).  Though 
admittedly the problem could somehow be in the MSR code I'm using.

> mWatts are for processor power not system power. Below data is
> calculated on fam15h model 60h which is low power platform. Even
> though the method has a minor mistake, the processor power should be
> in mWatts field.

I have an actual wall-mounted power meter hooked up to my system and the 
difference from idle to all-cores-busy is 20W, so I would think that that 
the results we find with perf should be >1W at least.

Vince