linux-kernel - Re: [PATCH RFC 4/9] perf jevents: Add sys_events_find_events

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]

Date:   Thu, 13 Jul 2023 16:06:46 +0100
From:   John Garry <john.g.garry@...cle.com>
To:     Ian Rogers <irogers@...gle.com>
Cc:     acme@...nel.org, namhyung@...nel.org, jolsa@...nel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        renyu.zj@...ux.alibaba.com, shangxiaojing@...wei.com,
        kjain@...ux.ibm.com, kan.liang@...ux.intel.com
Subject: Re: [PATCH RFC 4/9] perf jevents: Add sys_events_find_events_table()

On 12/07/2023 18:52, Ian Rogers wrote:
>> To be crystal clear, when you say ">1 PMU", do you mean ">1 PMU instance
>> of the same type" or ">1 PMU type"?
> So I'm meaning that if you have a MetricExpr where the events are from
>> 1 PMU, for example memory bandwidth coming from uncore PMUs and then
> instructions from a core PMU, and you do something like a ratio
> between these two.
> 
>>    in a metric wouldn't work though as it would
>>> appear the event was missing. Having the metric specify the PMU avoids
>>> these problems, but is verbose.
>> The message I'm getting - correct me if I am wrong - is that you would
>> still prefer the PMU specified per event in metric expr, right? We don't
>> do that exactly for sys PMU metrics today - we specify "Unit" instead, like:
>>
>> MetricExpr: "sys_pmu_bar_event_foo1 + sys_pmu_bar_event_foo2"
>> Compat: "baz"
>> Unit:"sys_pmu_bar"
>>
>> And so you prefer something like the following, right?
>> MetricExpr: "sys_pmu_foo@...1@ + sys_pmu_foo@...2@"
>>
>> If so, I think that is ok - I just want to get rid of Unit and Compat.
> I think we're agreeing 😄 

Ok, fine. I need to check on implementing support for that.

Then would you have any idea for testing here?

What I do is to ensure that if we 2x tables like following for separate 
SoCs:

soc_a.json


{
		"MetricExpr": "pmu_unit@...nt_foo@ * pmu_unit@...nt_bar@ * 1",
		"MetricName": "metric_baz",
},
{
		"EventCode": "0x84",
		"EventName": "event_foo ",
		"Compat": "0x00000030",
		"Unit": "pmu_unit"
},
{
		"EventCode": "0x85",
		"EventName": "event_bar ",
		"Compat": "0x00000030",
		"Unit": "pmu_unit"
},



soc_b.json


{
		"MetricExpr": "pmu_unit@...nt_foo@ * pmu_unit@...nt_bar@ * 2",
		"MetricName": "metric_baz",
},
{
		"EventCode": "0x84",
		"EventName": "event_foo ",
		"Compat": "0x00000040",
		"Unit": "pmu_unit"
},
{
		"EventCode": "0x85",
		"EventName": "event_bar ",
		"Compat": "0x00000040",
		"Unit": "pmu_unit"
},

And we have a pmu with name and hw id matching "pmu_unit" and 
"0x00000040" present, that we select metric metric_baz for soc_b

>I think Unit may be useful, say on Intel
> hybrid I want the tma_fround_bound metric on just cpu_atom. Currently
> the use of Unit is messy for metrics, ie uncore metrics are associated
> with core PMUs, and what to do with a MetricExpr with >1 PMU. I think
> we're learning from trying. I'm just hoping the migration to a sysfs
> style layout will still be possible, as I can see lots of upside in
> terms of testing, 1 approach, etc.

Do you have an RFC or something for this "sysfs style layout"? I think 
that it would be easier for me to understand your idea by seeing the SW.

Thanks,
John