Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Song Liu <songliubraving@fb.com>
To:     Jiri Olsa <jolsa@redhat.com>
CC:     Song Liu <song@kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        Namhyung Kim <namhyung@kernel.org>,
        "jolsa@kernel.org" <jolsa@kernel.org>
Subject: Re: [PATCH v2 3/3] perf-stat: introduce config
 stat.bpf-counter-events
Thread-Topic: [PATCH v2 3/3] perf-stat: introduce config
 stat.bpf-counter-events
Thread-Index: AQHXK0YG4LdD7IbPc0ehmtAjm2+fxaqqg16AgABRlYCAAAtnAIAAAjCAgAAEzwCAAAZpgA==
Date:   Thu, 8 Apr 2021 18:08:20 +0000
Message-ID: <FDBEC7CA-7F74-4494-93B3-7E5758E5DED9@fb.com>
References: <20210407003601.619158-1-song@kernel.org>
 <20210407003601.619158-4-song@kernel.org> <YG7tU/mVxQZLNCYL@krava>
 <FA667178-09F3-48C5-891C-9E44744276C0@fb.com> <YG87VLdSrhG0xSDj@krava>
 <0106D99A-5CBB-4CC4-B6F5-1B795E9B8274@fb.com> <YG9BMss16qFOjhos@krava>
In-Reply-To: <YG9BMss16qFOjhos@krava>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4722273CE1F7AC4AA028C7FDF79AEB18@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b71f512-6ea9-4ec6-5adc-08d8fab94b2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 18:08:20.9023
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: esl02lgD62XWZjyizRIRtqDvRT5Cvf2dkdFBcnSpRUxUHe3Kf4ESK1V8Ad/rnlADvVAD+bpWF5BTlV88UWVQoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB4248
X-OriginatorOrg: fb.com
X-Proofpoint-GUID: yUpvKsPZ0MLBhP-twyQsN8BM5l6Lfic4
X-Proofpoint-ORIG-GUID: yUpvKsPZ0MLBhP-twyQsN8BM5l6Lfic4
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761
 definitions=2021-04-08_04:2021-04-08,2021-04-08 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 mlxscore=0 adultscore=0
 spamscore=0 impostorscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999
 phishscore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1015
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2104080120
X-FB-Internal: deliver
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Apr 8, 2021, at 10:45 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>=20
> On Thu, Apr 08, 2021 at 05:28:10PM +0000, Song Liu wrote:
>>=20
>>=20
>>> On Apr 8, 2021, at 10:20 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>>>=20
>>> On Thu, Apr 08, 2021 at 04:39:33PM +0000, Song Liu wrote:
>>>>=20
>>>>=20
>>>>> On Apr 8, 2021, at 4:47 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>>>>>=20
>>>>> On Tue, Apr 06, 2021 at 05:36:01PM -0700, Song Liu wrote:
>>>>>> Currently, to use BPF to aggregate perf event counters, the user use=
s
>>>>>> --bpf-counters option. Enable "use bpf by default" events with a con=
fig
>>>>>> option, stat.bpf-counter-events. This is limited to hardware events =
in
>>>>>> evsel__hw_names.
>>>>>>=20
>>>>>> This also enables mixed BPF event and regular event in the same sess=
sion.
>>>>>> For example:
>>>>>>=20
>>>>>> perf config stat.bpf-counter-events=3Dinstructions
>>>>>> perf stat -e instructions,cs
>>>>>>=20
>>>>>=20
>>>>> so if we are mixing events now, how about uing modifier for bpf count=
ers,
>>>>> instead of configuring .perfconfig list we could use:
>>>>>=20
>>>>> perf stat -e instructions:b,cs
>>>>>=20
>>>>> thoughts?
>>>>>=20
>>>>> the change below adds 'b' modifier and sets 'evsel::bpf_counter',
>>>>> feel free to use it
>>>>=20
>>>> I think we will need both 'b' modifier and .perfconfig configuration.=
=20
>>>> For systems with BPF-managed perf events running in the background,=20
>>>=20
>>> hum, I'm not sure I understand what that means.. you mean there
>>> are tools that run perf stat so you don't want to change them?
>>=20
>> We have tools that do perf_event_open(). I will change them to use=20
>> BPF managed perf events for "cycles" and "instructions". Since these=20
>> tools are running 24/7, perf-stat on the system should use BPF managed
>> "cycles" and "instructions" by default.=20
>=20
> well if you are already changing the tools why not change them to add
> modifier.. but I don't mind adding that .perfconfig stuff if you need
> that

The tools I mentioned here don't use perf-stat, they just use=20
perf_event_open() and read the perf events fds. We want a config to make
"cycles" to use BPF by default, so that when the user (not these tools)
runs perf-stat, it will share PMCs with those events by default.=20

>=20
>>=20
>>>=20
>>>> .perfconfig makes sure perf-stat sessions will share PMCs with these=20
>>>> background monitoring tools. 'b' modifier, on the other hand, is usefu=
l
>>>> when the user knows there is opportunity to share the PMCs.=20
>>>>=20
>>>> Does this make sense?=20
>>>=20
>>> if there's reason for that then sure.. but let's not limit that just
>>> on HARDWARE events only.. there are RAW events with the same demand
>>> for this feature.. why don't we let user define any event for this?
>>=20
>> I haven't found a good way to config RAW events. I guess RAW events=20
>> could use 'b' modifier?=20
> any event uing the pmu notation like cpu/instructions/

Can we do something like "perf config stat.bpf-counter-events=3Dcpu/*" mean=
s=20
all "cpu/xx" events use BPF by default?

Thanks,
Song

>=20
> we can allow any event to be BPF-managed, right? IIUC we don't care,
> the code will work with any event

Yes, the code works with any event. =