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

["Liang, Kan" <kan.liang@linux.intel.com>]

On 2/20/2019 6:12 AM, Peter Zijlstra wrote:
> On Tue, Feb 19, 2019 at 12:00:02PM -0800, kan.liang@linux.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