linux-kernel - Re: [PATCH RFC 4/7] perf pmu: Rename uncore symbols to include system PMUs

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: <52e18a50-1e62-f2fa-7639-f96268c5d243@huawei.com>
Date:   Tue, 11 Feb 2020 15:36:39 +0000
From:   John Garry <john.garry@...wei.com>
To:     Jiri Olsa <jolsa@...hat.com>
CC:     <peterz@...radead.org>, <mingo@...hat.com>, <acme@...nel.org>,
        <mark.rutland@....com>, <alexander.shishkin@...ux.intel.com>,
        <namhyung@...nel.org>, <will@...nel.org>, <ak@...ux.intel.com>,
        <linuxarm@...wei.com>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <suzuki.poulose@....com>,
        <james.clark@....com>, <zhangshaokun@...ilicon.com>,
        <robin.murphy@....com>
Subject: Re: [PATCH RFC 4/7] perf pmu: Rename uncore symbols to include system
 PMUs

On 11/02/2020 14:43, Jiri Olsa wrote:
>> root@(none)$ pwd
>> /sys/bus/event_source/devices/smmuv3_pmcg_100020
>> root@(none)$ ls -l
>> total 0
>> -r--r--r--    1 root     root          4096 Feb 10 14:50 cpumask
>> drwxr-xr-x    2 root     root             0 Feb 10 14:50 events
>> drwxr-xr-x    2 root     root             0 Feb 10 14:50 format
>> -rw-r--r--    1 root     root          4096 Feb 10 14:50
>> perf_event_mux_interval_ms
>> drwxr-xr-x    2 root     root             0 Feb 10 14:50 power
>> lrwxrwxrwx    1 root     root             0 Feb 10 14:50 subsystem ->
>> ../../bus/event_source
>> -r--r--r--    1 root     root          4096 Feb 10 14:50 type
>> -rw-r--r--    1 root     root          4096 Feb 10 14:50 uevent
>>
>>
>> Other PMU drivers which I have checked in drivers/perf also have the same.
>>
>> Indeed I see no way to differentiate whether a PMU is an uncore or system.
>> So that is why I change the name to cover both. Maybe there is a better name
>> than the verbose pmu_is_uncore_or_sys().
>>
>>> I don't see the connection here with the sysid or '_sys' checking,
>>> that's just telling which ID to use when looking for an alias, no?
>> So the connection is that in perf_pmu__find_map(), for a given PMU, the
>> matching is now extended from only core or uncore PMUs to also these system
>> PMUs. And I use the sysid to find an aliasing table for any system PMUs
>> present.

Hi Jirka,

 > I see.. can't we just check sysid for uncore PMUs?

x86 will still alias PMUs (uncore or CPU) based on an alias table 
matched to the cpuid, as it is today. x86 has the benefit of fixed 
uncore PMUs for a given cpuid.

For other archs whose uncore or system PMUs are not fixed for a given 
CPU - like arm - we will support matching uncore and system PMUs on 
cpuid or sysid.

Uncore PMUs are a grey area for arm, as they may or may not be tied to a 
specific cpuid, so we will need to support both matching methods.

because
 > that's what the code is doing, right?

Not exactly.

The code will match on an alias table matched to the cpuid and also an 
alias table matched to the sysid (if perf could actually get a sysid and 
there is a table matching that sysid).

I hope that this makes sense....

having pmu_is_uncore_or_sys
 > makes me think there's some sysid-type PMU
 >
 > jirka
 >

Thanks,
John