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>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        "acme@kernel.org" <acme@kernel.org>,
        "acme@redhat.com" <acme@redhat.com>,
        "namhyung@kernel.org" <namhyung@kernel.org>,
        "jolsa@kernel.org" <jolsa@kernel.org>
Subject: Re: [PATCH v5 5/5] perf-stat: introduce bpf_counter_ops->disable()
Thread-Topic: [PATCH v5 5/5] perf-stat: introduce bpf_counter_ops->disable()
Thread-Index: AQHXOhwex5gB4i62NU+zgG+lriKiJqrHUbkAgAAOWgCAAO6+AIAAdISA
Date:   Tue, 27 Apr 2021 19:30:28 +0000
Message-ID: <5257A59A-CC47-4CA7-9C15-CD6E20DC4BD0@fb.com>
References: <20210425214333.1090950-1-song@kernel.org>
 <20210425214333.1090950-6-song@kernel.org> <YIcwRj4WtsZln4SR@krava>
 <CDBE5630-F7F0-494D-BFA8-33742D831C2D@fb.com> <YIgElir6KJCoygX5@krava>
In-Reply-To: <YIgElir6KJCoygX5@krava>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B5793A11AE96264A845A5C17922818B6@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 600a62d9-929e-4a50-1ff4-08d909b2ea3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2021 19:30:28.5935
 (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: Cm2zD6OcuukuszDE6pwprdBdiLBCSjicqrdJI1z95IGqoUg387qvNDjtgC7E0iVcXPuWasR/6oZbcdtCIHyYsw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR15MB4204
X-OriginatorOrg: fb.com
X-Proofpoint-ORIG-GUID: JnyqegSKrt8kJxMBqPWdYU06TUMEs6bC
X-Proofpoint-GUID: JnyqegSKrt8kJxMBqPWdYU06TUMEs6bC
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761
 definitions=2021-04-27_11:2021-04-27,2021-04-27 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 mlxlogscore=999
 impostorscore=0 malwarescore=0 spamscore=0 clxscore=1015
 lowpriorityscore=0 priorityscore=1501 mlxscore=0 phishscore=0 bulkscore=0
 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2104060000 definitions=main-2104270129
X-FB-Internal: deliver
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Apr 27, 2021, at 5:33 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>=20
> On Mon, Apr 26, 2021 at 10:18:57PM +0000, Song Liu wrote:
>>=20
>>=20
>>> On Apr 26, 2021, at 2:27 PM, Jiri Olsa <jolsa@redhat.com> wrote:
>>>=20
>>> On Sun, Apr 25, 2021 at 02:43:33PM -0700, Song Liu wrote:
>>>=20
>>> SNIP
>>>=20
>>>> +static inline int bpf_counter__disable(struct evsel *evsel __maybe_un=
used)
>>>> +{
>>>> +	return 0;
>>>> +}
>>>> +
>>>> static inline int bpf_counter__read(struct evsel *evsel __maybe_unused=
)
>>>> {
>>>> 	return -EAGAIN;
>>>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>>>> index d29a8a118973c..e71041c890102 100644
>>>> --- a/tools/perf/util/evlist.c
>>>> +++ b/tools/perf/util/evlist.c
>>>> @@ -17,6 +17,7 @@
>>>> #include "evsel.h"
>>>> #include "debug.h"
>>>> #include "units.h"
>>>> +#include "bpf_counter.h"
>>>> #include <internal/lib.h> // page_size
>>>> #include "affinity.h"
>>>> #include "../perf.h"
>>>> @@ -421,6 +422,9 @@ static void __evlist__disable(struct evlist *evlis=
t, char *evsel_name)
>>>> 	if (affinity__setup(&affinity) < 0)
>>>> 		return;
>>>>=20
>>>> +	evlist__for_each_entry(evlist, pos)
>>>> +		bpf_counter__disable(pos);
>>>=20
>>> I was wondering why you don't check evsel__is_bpf like
>>> for the enable case.. and realized that we don't skip
>>> bpf evsels in __evlist__enable and __evlist__disable
>>> like we do in read_affinity_counters
>>>=20
>>> so I guess there's extra affinity setup and bunch of
>>> wrong ioctls being called?
>>=20
>> We actually didn't do wrong ioctls because the following check:
>>=20
>>       if (... || !pos->core.fd)
>>                continue;
>>=20
>> in __evlist__enable and __evlist__disable. That we don't allocate=20
>> core.fd for is_bpf events.=20
>>=20
>> It is probably good to be more safe with an extra check of=20
>> evsel__is_bpf(). But it is not required with current code.=20
>=20
> hum, but it will do all the affinity setup no? for no reason,
> if there's no non-bpb event

Yes, it will do the affinity setup. Let me see how to get something
like all_counters_use_bpf here (or within builtin-stat.c).

Thanks,
Song