linux-kernel - Re: [PATCH 01/10] perf/x86/intel: Introduce a concept "domain" as the scope of counters

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: <a339c9b9-e704-318d-f53f-058a8b2d7898@linux.intel.com>
Date:   Tue, 5 Mar 2019 15:32:37 -0500
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     tglx@...utronix.de, acme@...nel.org, mingo@...hat.com,
        x86@...nel.org, linux-kernel@...r.kernel.org, len.brown@...el.com,
        jolsa@...hat.com, namhyung@...nel.org, eranian@...gle.com,
        ak@...ux.intel.com
Subject: Re: [PATCH 01/10] perf/x86/intel: Introduce a concept "domain" as the
 scope of counters

Hi Peter,

Is the idea (abstract common topology related codes for perf modules) 
the right direction?
I'm asking because I'm going to submit uncore codes for new platforms. 
I'm not sure if the new code should base on this series.

Could you please share your opinion?

If it's the right direction, could you please review the patch 1-4?
They are for previous platforms and can be merged separately.

If it's not the right time to do the abstraction, I will re-write the 
patches to only specially handle CLX-AP for now. For example, per-die 
counters can share the code with per-package counters by introducing a 
new variable 'bool die_scope' and checking the variable before calling 
any topology related functions.
But that's only a temporary solution for CLX-AP. We still need to add 
dedicated per-die PMU support later, if both per-die and per-package 
counters are supported on the same platforms.

Thanks,
Kan

On 2/20/2019 9:36 AM, Liang, Kan wrote:
> 
> 
> On 2/20/2019 6:12 AM, Peter Zijlstra wrote:
>> On Tue, Feb 19, 2019 at 12:00:02PM -0800, kan.liang@...ux.intel.com 
>> wrote:
>>> It's very useful to abstract several common topology related codes for
>>> these modules to reduce the code redundancy.
>>
>>>   3 files changed, 96 insertions(+), 1 deletion(-)
>>
>> So you add 100 lines, so we can remove lines when we start to use this.
>>
>> Except all 3 follow up patches that employ this, all add more lines
>> still:
> 
> The previous implementation assumes that there is only one or two types 
> of counters (per core or per package). The proposed solution breaks the 
> assumption and can support more types of counters. The new 
> infrastructure needs more lines. But with more and more types 
> introduced, we can expect less lines in total with the proposed solution.
> 
>>   1 file changed, 184 insertions(+), 157 deletions(-)
> 
> This is cstate which supports two types of counters (per core and per 
> package) now.
> 
>>   3 files changed, 164 insertions(+), 80 deletions(-)
>>   1 file changed, 224 insertions(+), 82 deletions(-)
>>
> 
> They are uncore and rapl which only supports one type of counters (per 
> package) now.
> 
> When there is only one type, the proposed solution has more lines.
> But when there are two types, the proposed solution has similar number 
> of lines as previous implementation.
> In this trend, I expect that the proposed solution has less lines when 
> there are three or more types.
> 
> With die introduced, there are at least two types of counters for rapl 
> and uncore, and three types for cstate. In total, we should see less lines.
> 
> There may be more types of counters added later. In 8.9.1 Hierarchical 
> Mapping of Shared Resources of SDM vol3A, it document 7 APIC_ID fields 
> (cluster, package, die, tile, module, core and SMT). There are only 4 
> types of counters for now.
> 
> 
> Thanks,
> Kan