linux-kernel - Re: [PATCH v2 5/5] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160121165958.GF21930@pd.tnic>
Date:	Thu, 21 Jan 2016 17:59:58 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Huang Rui <ray.huang@....com>, Ingo Molnar <mingo@...nel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Robert Richter <rric@...nel.org>,
	Jacob Shin <jacob.w.shin@...il.com>,
	John Stultz <john.stultz@...aro.org>,
	Fr�d�ric Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, spg_linux_kernel@....com,
	x86@...nel.org, Guenter Roeck <linux@...ck-us.net>,
	Andreas Herrmann <herrmann.der.user@...glemail.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Aaron Lu <aaron.lu@...el.com>
Subject: Re: [PATCH v2 5/5] perf/x86/amd/power: Add AMD accumulated power
 reporting mechanism

On Thu, Jan 21, 2016 at 04:10:40PM +0100, Peter Zijlstra wrote:
> > > > +	cpumask_clear(pmu->mask);
> > > > +	cpumask_clear(pmu->tmp_mask);
> > > >  
> > > >  	for (i = 0; i < cores_per_cu; i++)
> > > > +		cpumask_set_cpu(i, pmu->mask);
> > > >  
> > > > +	cpumask_shift_left(pmu->mask, pmu->mask, cu * cores_per_cu);
> > > 
> > > Couldn't you simply use topology_sibling_cpumask(cpu) instead?
> > > 
> > 
> > Looks like we couldn't. That's because cores number per cu (compute
> > unit) is got by CPUID 0x8000001e EBX. That relies on the CPU hardware.
> 
> Borislav? I thought the AMD compute unit stuff was modeled as the SMT
> topology.

I would think so too:

	smp_num_siblings = ((ebx >> 8) & 3) + 1;

gets set based on that CPUID leaf above. And that value is
CoresPerComputeUnit which needs to be incremented by 1 to get the actual
count of cores in a compute unit.

And that participates in the setting of topology_sibling_cpumask() in
set_cpu_sibling_map().

And that looks correct on my system here:

$ grep -EriIn . /sys/devices/system/cpu/cpu?/topology/* | grep thread_siblings
/sys/devices/system/cpu/cpu0/topology/thread_siblings:1:03
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:1:0-1
/sys/devices/system/cpu/cpu1/topology/thread_siblings:1:03
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1:0-1
/sys/devices/system/cpu/cpu2/topology/thread_siblings:1:0c
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:1:2-3
/sys/devices/system/cpu/cpu3/topology/thread_siblings:1:0c
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:1:2-3
/sys/devices/system/cpu/cpu4/topology/thread_siblings:1:30
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:1:4-5
/sys/devices/system/cpu/cpu5/topology/thread_siblings:1:30
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:1:4-5
/sys/devices/system/cpu/cpu6/topology/thread_siblings:1:c0
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:1:6-7
/sys/devices/system/cpu/cpu7/topology/thread_siblings:1:c0
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:1:6-7

and when we look at what CPUID reports:

$ cpuid -r | grep -E "^\s+0x8000001e" | awk '{ print $4 }'
ebx=0x00000100
ebx=0x00000100
ebx=0x00000101
ebx=0x00000101
ebx=0x00000102
ebx=0x00000102
ebx=0x00000103
ebx=0x00000103

We see that [15:8] is CoresPerComputeUnit which is + 1, so 2 cores per
compute unit.

And slice [7:0] gives the compute unit (CU) id of each core, so cores 0
and 1 are CU0, 2 and 3 are CU1 and so on...

So Rui, why do you say you can't use topology_sibling_cpumask()?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.