From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759856AbcAURAb (ORCPT ); Thu, 21 Jan 2016 12:00:31 -0500 Received: from mail.skyhub.de ([78.46.96.112]:39920 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759783AbcAURA0 (ORCPT ); Thu, 21 Jan 2016 12:00:26 -0500 Date: Thu, 21 Jan 2016 17:59:58 +0100 From: Borislav Petkov To: Peter Zijlstra Cc: Huang Rui , Ingo Molnar , Andy Lutomirski , Thomas Gleixner , Robert Richter , Jacob Shin , John Stultz , =?utf-8?B?RnLvv71k77+9cmlj?= Weisbecker , linux-kernel@vger.kernel.org, spg_linux_kernel@amd.com, x86@kernel.org, Guenter Roeck , Andreas Herrmann , Suravee Suthikulpanit , Aravind Gopalakrishnan , Fengguang Wu , Aaron Lu Subject: Re: [PATCH v2 5/5] perf/x86/amd/power: Add AMD accumulated power reporting mechanism Message-ID: <20160121165958.GF21930@pd.tnic> References: <1452739808-11871-1-git-send-email-ray.huang@amd.com> <1452739808-11871-6-git-send-email-ray.huang@amd.com> <20160119121250.GA6344@twins.programming.kicks-ass.net> <20160120044823.GA13477@hr-amur2> <20160120092244.GH6357@twins.programming.kicks-ass.net> <20160121070437.GA15130@hr-amur2> <20160121090257.GC6357@twins.programming.kicks-ass.net> <20160121144233.GA16294@hr-amur2> <20160121151040.GO6356@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160121151040.GO6356@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.