Message ID | 20230715032915.97146-6-yangjihong1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp2447vqt; Fri, 14 Jul 2023 20:48:42 -0700 (PDT) X-Google-Smtp-Source: APBJJlFHC1jeFmcpZd0o9HiQKKb59hBj4R0MovonY713/MUmAE0fqAgvH3GEEt7VCQrHyD+ArhBO X-Received: by 2002:a17:907:7ba8:b0:989:21e4:6c6d with SMTP id ne40-20020a1709077ba800b0098921e46c6dmr5085550ejc.28.1689392922421; Fri, 14 Jul 2023 20:48:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689392922; cv=none; d=google.com; s=arc-20160816; b=L2jfnvZK9GznG/S3ycacDDFI1FxusfUgM93e9RNVIrNlK5HI37TTXK8PmPs+57tDaF NvDWjFv1KjQFswPIB4JFx1WvgeyZtqJUZ+ptQdAWRw3HA/BkWhtlsH5pxCdJIMWZ3cdP cv25c2bhz6Pmoitu+yrhigsRi3qLBWFEHqwdb6QDfzsl2bdq9z8UX7noio76vYc6jMWW Ppfsw87o5LH1NEc78Fv2CNrbisz7azOwlAYydlQkIeVLPzsEY8VsnNxyOZGt7OPnzOBT ArVc4balhXQPnphU3VjThN+85eZL2a6F9QkRJx4pP+QC2BJeG6AU+DgEeSPNLbpcm+EI Ic3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=KYyF7GMwdJnmcSDi3ym4N6moo/bcg8n7UAWJpc/Ey+o=; fh=Ib1wi7jRbo+eNDLEErvWCJx+cnUm87PkGFthhdFf08Y=; b=AZBczwfI0v/rFlj3s1rV+/KTPDcqYhJf5GSoXG/PPQLHoTkfxCIx6MwnF1BOkT4Sck Nb29BprbCcMdC9qTqhwoKaH4uFtC3MupreFuNkCc6dx0aUZ+C0dVKoDgvVua8E7+azsK 43hWUIUqWMwdkjVUa+JMD3y0zfenTYLaY8zXHTGVBKOgAEGdaDg1Bu2VHGTPqEkcCTY8 U9jEeTJ0iHQnG/PipOizClxnvUPL13Bq+7IyDZU8227IZyMTgTZLTRUU24NGwRdSZ3el gAxV1fOdq6UODX92elD+xNeWYU1JdYqsts1FzR5YFZx6yccBEGxluYSZbQFOMlNg6987 HQkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gz10-20020a170906f2ca00b009886b606a71si9767336ejb.696.2023.07.14.20.48.19; Fri, 14 Jul 2023 20:48:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230146AbjGODbq (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Fri, 14 Jul 2023 23:31:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229980AbjGODbh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Jul 2023 23:31:37 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EB753A97; Fri, 14 Jul 2023 20:31:36 -0700 (PDT) Received: from kwepemm600003.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4R2v1q5TclzNm9v; Sat, 15 Jul 2023 11:28:15 +0800 (CST) Received: from localhost.localdomain (10.67.174.95) by kwepemm600003.china.huawei.com (7.193.23.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Sat, 15 Jul 2023 11:31:33 +0800 From: Yang Jihong <yangjihong1@huawei.com> To: <peterz@infradead.org>, <mingo@redhat.com>, <acme@kernel.org>, <mark.rutland@arm.com>, <alexander.shishkin@linux.intel.com>, <jolsa@kernel.org>, <namhyung@kernel.org>, <irogers@google.com>, <adrian.hunter@intel.com>, <kan.liang@linux.intel.com>, <james.clark@arm.com>, <tmricht@linux.ibm.com>, <ak@linux.intel.com>, <anshuman.khandual@arm.com>, <linux-kernel@vger.kernel.org>, <linux-perf-users@vger.kernel.org> CC: <yangjihong1@huawei.com> Subject: [PATCH v2 5/7] perf evlist: Skip dummy event sample_type check for evlist_config Date: Sat, 15 Jul 2023 03:29:13 +0000 Message-ID: <20230715032915.97146-6-yangjihong1@huawei.com> X-Mailer: git-send-email 2.30.GIT In-Reply-To: <20230715032915.97146-1-yangjihong1@huawei.com> References: <20230715032915.97146-1-yangjihong1@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.174.95] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600003.china.huawei.com (7.193.23.202) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771456873196304336 X-GMAIL-MSGID: 1771456873196304336 |
Series |
perf record: Track sideband events for all CPUs when tracing selected CPUs
|
|
Commit Message
Yang Jihong
July 15, 2023, 3:29 a.m. UTC
The dummp event does not contain sampls data. Therefore, sample_type does
not need to be checked.
Currently, the sample id format of the actual sampling event may be changed
after the dummy event is added.
Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
---
tools/perf/util/record.c | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On 15/07/23 06:29, Yang Jihong wrote: > The dummp event does not contain sampls data. Therefore, sample_type does > not need to be checked. > > Currently, the sample id format of the actual sampling event may be changed > after the dummy event is added. > > Signed-off-by: Yang Jihong <yangjihong1@huawei.com> > --- > tools/perf/util/record.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c > index 9eb5c6a08999..0240be3b340f 100644 > --- a/tools/perf/util/record.c > +++ b/tools/perf/util/record.c > @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call > evlist__for_each_entry(evlist, evsel) { > if (evsel->core.attr.sample_type == first->core.attr.sample_type) > continue; > + > + /* > + * Skip the sample_type check for the dummy event > + * because it does not have any samples anyway. > + */ > + if (evsel__is_dummy_event(evsel)) > + continue; Sideband event records have "ID samples" so the sample type still matters. > use_sample_identifier = perf_can_sample_identifier(); > break; > }
Hello, On 2023/7/17 22:41, Adrian Hunter wrote: > On 15/07/23 06:29, Yang Jihong wrote: >> The dummp event does not contain sampls data. Therefore, sample_type does >> not need to be checked. >> >> Currently, the sample id format of the actual sampling event may be changed >> after the dummy event is added. >> >> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >> --- >> tools/perf/util/record.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >> index 9eb5c6a08999..0240be3b340f 100644 >> --- a/tools/perf/util/record.c >> +++ b/tools/perf/util/record.c >> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >> evlist__for_each_entry(evlist, evsel) { >> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >> continue; >> + >> + /* >> + * Skip the sample_type check for the dummy event >> + * because it does not have any samples anyway. >> + */ >> + if (evsel__is_dummy_event(evsel)) >> + continue; > > Sideband event records have "ID samples" so the sample type still matters. > Okay, will remove this patch in next version. Can I ask a little more about this? Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. *Sideband event records have "ID samples" so the sample type still matters.* Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? Thanks, Yang
On 18/07/23 12:30, Yang Jihong wrote: > Hello, > > On 2023/7/17 22:41, Adrian Hunter wrote: >> On 15/07/23 06:29, Yang Jihong wrote: >>> The dummp event does not contain sampls data. Therefore, sample_type does >>> not need to be checked. >>> >>> Currently, the sample id format of the actual sampling event may be changed >>> after the dummy event is added. >>> >>> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >>> --- >>> tools/perf/util/record.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >>> index 9eb5c6a08999..0240be3b340f 100644 >>> --- a/tools/perf/util/record.c >>> +++ b/tools/perf/util/record.c >>> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >>> evlist__for_each_entry(evlist, evsel) { >>> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >>> continue; >>> + >>> + /* >>> + * Skip the sample_type check for the dummy event >>> + * because it does not have any samples anyway. >>> + */ >>> + if (evsel__is_dummy_event(evsel)) >>> + continue; >> >> Sideband event records have "ID samples" so the sample type still matters. >> > Okay, will remove this patch in next version. > > Can I ask a little more about this? > > Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. > > However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. > > That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. > > *Sideband event records have "ID samples" so the sample type still matters.* > > Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? No. There are additional members as defined by struct sample_id for PERF_RECORD_MMAP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h?h=v6.4#n872
Hello, On 2023/7/18 17:56, Adrian Hunter wrote: > On 18/07/23 12:30, Yang Jihong wrote: >> Hello, >> >> On 2023/7/17 22:41, Adrian Hunter wrote: >>> On 15/07/23 06:29, Yang Jihong wrote: >>>> The dummp event does not contain sampls data. Therefore, sample_type does >>>> not need to be checked. >>>> >>>> Currently, the sample id format of the actual sampling event may be changed >>>> after the dummy event is added. >>>> >>>> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >>>> --- >>>> tools/perf/util/record.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >>>> index 9eb5c6a08999..0240be3b340f 100644 >>>> --- a/tools/perf/util/record.c >>>> +++ b/tools/perf/util/record.c >>>> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >>>> evlist__for_each_entry(evlist, evsel) { >>>> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >>>> continue; >>>> + >>>> + /* >>>> + * Skip the sample_type check for the dummy event >>>> + * because it does not have any samples anyway. >>>> + */ >>>> + if (evsel__is_dummy_event(evsel)) >>>> + continue; >>> >>> Sideband event records have "ID samples" so the sample type still matters. >>> >> Okay, will remove this patch in next version. >> >> Can I ask a little more about this? >> >> Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. >> >> However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. >> >> That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. >> >> *Sideband event records have "ID samples" so the sample type still matters.* >> >> Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? > > No. There are additional members as defined by struct sample_id for PERF_RECORD_MMAP: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h?h=v6.4#n872 > I'm sorry, maybe my comments didn't make it clear. I mean, can we skip the "use_sample_identifier" check here? That is, set sample_type to *XXX|PERF_SAMPLE_ID* instead of *XXX|PERF_SAMPLE_IDENTIFICATION* Thanks, Yang
On 18/07/23 13:17, Yang Jihong wrote: > Hello, > > On 2023/7/18 17:56, Adrian Hunter wrote: >> On 18/07/23 12:30, Yang Jihong wrote: >>> Hello, >>> >>> On 2023/7/17 22:41, Adrian Hunter wrote: >>>> On 15/07/23 06:29, Yang Jihong wrote: >>>>> The dummp event does not contain sampls data. Therefore, sample_type does >>>>> not need to be checked. >>>>> >>>>> Currently, the sample id format of the actual sampling event may be changed >>>>> after the dummy event is added. >>>>> >>>>> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >>>>> --- >>>>> tools/perf/util/record.c | 7 +++++++ >>>>> 1 file changed, 7 insertions(+) >>>>> >>>>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >>>>> index 9eb5c6a08999..0240be3b340f 100644 >>>>> --- a/tools/perf/util/record.c >>>>> +++ b/tools/perf/util/record.c >>>>> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >>>>> evlist__for_each_entry(evlist, evsel) { >>>>> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >>>>> continue; >>>>> + >>>>> + /* >>>>> + * Skip the sample_type check for the dummy event >>>>> + * because it does not have any samples anyway. >>>>> + */ >>>>> + if (evsel__is_dummy_event(evsel)) >>>>> + continue; >>>> >>>> Sideband event records have "ID samples" so the sample type still matters. >>>> >>> Okay, will remove this patch in next version. >>> >>> Can I ask a little more about this? >>> >>> Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. >>> >>> However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. >>> >>> That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. >>> >>> *Sideband event records have "ID samples" so the sample type still matters.* >>> >>> Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? >> >> No. There are additional members as defined by struct sample_id for PERF_RECORD_MMAP: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h?h=v6.4#n872 >> > I'm sorry, maybe my comments didn't make it clear. > I mean, can we skip the "use_sample_identifier" check here? > > That is, set sample_type to *XXX|PERF_SAMPLE_ID* instead of *XXX|PERF_SAMPLE_IDENTIFICATION* In general, when there are different values of sample_type, the PERF_SAMPLE_ID is needed to determine which is which. But PERF_SAMPLE_ID is not at a fixed position, so the sample_type is needed to find it. That is why PERF_SAMPLE_IDENTIFIER is better. Why do want to change it?
Hello, On 2023/7/18 18:29, Adrian Hunter wrote: > On 18/07/23 13:17, Yang Jihong wrote: >> Hello, >> >> On 2023/7/18 17:56, Adrian Hunter wrote: >>> On 18/07/23 12:30, Yang Jihong wrote: >>>> Hello, >>>> >>>> On 2023/7/17 22:41, Adrian Hunter wrote: >>>>> On 15/07/23 06:29, Yang Jihong wrote: >>>>>> The dummp event does not contain sampls data. Therefore, sample_type does >>>>>> not need to be checked. >>>>>> >>>>>> Currently, the sample id format of the actual sampling event may be changed >>>>>> after the dummy event is added. >>>>>> >>>>>> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >>>>>> --- >>>>>> tools/perf/util/record.c | 7 +++++++ >>>>>> 1 file changed, 7 insertions(+) >>>>>> >>>>>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >>>>>> index 9eb5c6a08999..0240be3b340f 100644 >>>>>> --- a/tools/perf/util/record.c >>>>>> +++ b/tools/perf/util/record.c >>>>>> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >>>>>> evlist__for_each_entry(evlist, evsel) { >>>>>> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >>>>>> continue; >>>>>> + >>>>>> + /* >>>>>> + * Skip the sample_type check for the dummy event >>>>>> + * because it does not have any samples anyway. >>>>>> + */ >>>>>> + if (evsel__is_dummy_event(evsel)) >>>>>> + continue; >>>>> >>>>> Sideband event records have "ID samples" so the sample type still matters. >>>>> >>>> Okay, will remove this patch in next version. >>>> >>>> Can I ask a little more about this? >>>> >>>> Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. >>>> >>>> However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. >>>> >>>> That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. >>>> >>>> *Sideband event records have "ID samples" so the sample type still matters.* >>>> >>>> Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? >>> >>> No. There are additional members as defined by struct sample_id for PERF_RECORD_MMAP: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h?h=v6.4#n872 >>> >> I'm sorry, maybe my comments didn't make it clear. >> I mean, can we skip the "use_sample_identifier" check here? >> >> That is, set sample_type to *XXX|PERF_SAMPLE_ID* instead of *XXX|PERF_SAMPLE_IDENTIFICATION* > > In general, when there are different values of sample_type, the PERF_SAMPLE_ID is needed to determine which is which. > But PERF_SAMPLE_ID is not at a fixed position, so the sample_type is needed to find it. That is why PERF_SAMPLE_IDENTIFIER is better. > > Why do want to change it? Without this patch, we now add a system_wide tracking event and modify the sample_type of the actual sample event. For example, when we run: # perf record -e cycles -C 0 1. The default sample_type of the "cycles" is IP|TID|TIME|CPU|PERIOD. 2. Then add a system_wide sideband event whose sample_type is IP|TID|TIME|CPU. 3. The two sample_types are different. 4. Therefore, the evlist__config adds a PERF_SAMPLE_IDENTIFICATION to both sample_types instead of PERF_SAMPLE_ID. evlist__config { ... } else if (evlist->core.nr_entries > 1) { // One is cycles and the other is sideband . struct evsel *first = evlist__first(evlist); evlist__for_each_entry(evlist, evsel) { if (evsel->core.attr.sample_type == first->core.attr.sample_type) continue; use_sample_identifier = perf_can_sample_identifier(); // the sample_type of cycles is different from that of sideband. // Therefore, use_sample_identifier is set to true. break; } sample_id = true; } if (sample_id) { evlist__for_each_entry(evlist, evsel) evsel__set_sample_id(evsel, use_sample_identifier); // both cycles and sideband set PERF_SAMPLE_IDENTIFICATION } ... } The comparison of the sideband event sample_type is skipped so that the sample_type of the original cycles is not changed. It does not seem necessary to compare the sample_type of sidebband event. It is not an actual sample event, so I'd like to confirm that. If the change is as expected and necessary, then I'll remove the patch. Thanks, Yang
On 18/07/23 14:32, Yang Jihong wrote: > Hello, > > On 2023/7/18 18:29, Adrian Hunter wrote: >> On 18/07/23 13:17, Yang Jihong wrote: >>> Hello, >>> >>> On 2023/7/18 17:56, Adrian Hunter wrote: >>>> On 18/07/23 12:30, Yang Jihong wrote: >>>>> Hello, >>>>> >>>>> On 2023/7/17 22:41, Adrian Hunter wrote: >>>>>> On 15/07/23 06:29, Yang Jihong wrote: >>>>>>> The dummp event does not contain sampls data. Therefore, sample_type does >>>>>>> not need to be checked. >>>>>>> >>>>>>> Currently, the sample id format of the actual sampling event may be changed >>>>>>> after the dummy event is added. >>>>>>> >>>>>>> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >>>>>>> --- >>>>>>> tools/perf/util/record.c | 7 +++++++ >>>>>>> 1 file changed, 7 insertions(+) >>>>>>> >>>>>>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >>>>>>> index 9eb5c6a08999..0240be3b340f 100644 >>>>>>> --- a/tools/perf/util/record.c >>>>>>> +++ b/tools/perf/util/record.c >>>>>>> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >>>>>>> evlist__for_each_entry(evlist, evsel) { >>>>>>> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >>>>>>> continue; >>>>>>> + >>>>>>> + /* >>>>>>> + * Skip the sample_type check for the dummy event >>>>>>> + * because it does not have any samples anyway. >>>>>>> + */ >>>>>>> + if (evsel__is_dummy_event(evsel)) >>>>>>> + continue; >>>>>> >>>>>> Sideband event records have "ID samples" so the sample type still matters. >>>>>> >>>>> Okay, will remove this patch in next version. >>>>> >>>>> Can I ask a little more about this? >>>>> >>>>> Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. >>>>> >>>>> However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. >>>>> >>>>> That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. >>>>> >>>>> *Sideband event records have "ID samples" so the sample type still matters.* >>>>> >>>>> Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? >>>> >>>> No. There are additional members as defined by struct sample_id for PERF_RECORD_MMAP: >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h?h=v6.4#n872 >>>> >>> I'm sorry, maybe my comments didn't make it clear. >>> I mean, can we skip the "use_sample_identifier" check here? >>> >>> That is, set sample_type to *XXX|PERF_SAMPLE_ID* instead of *XXX|PERF_SAMPLE_IDENTIFICATION* >> >> In general, when there are different values of sample_type, the PERF_SAMPLE_ID is needed to determine which is which. >> But PERF_SAMPLE_ID is not at a fixed position, so the sample_type is needed to find it. That is why PERF_SAMPLE_IDENTIFIER is better. >> >> Why do want to change it? > > Without this patch, we now add a system_wide tracking event and modify the sample_type of the actual sample event. > > For example, when we run: > # perf record -e cycles -C 0 > > 1. The default sample_type of the "cycles" is IP|TID|TIME|CPU|PERIOD. > 2. Then add a system_wide sideband event whose sample_type is IP|TID|TIME|CPU. > 3. The two sample_types are different. > 4. Therefore, the evlist__config adds a PERF_SAMPLE_IDENTIFICATION to both sample_types instead of PERF_SAMPLE_ID. > > evlist__config { > ... > } else if (evlist->core.nr_entries > 1) { > // One is cycles and the other is sideband . > struct evsel *first = evlist__first(evlist); > > > evlist__for_each_entry(evlist, evsel) { > if (evsel->core.attr.sample_type == first->core.attr.sample_type) > continue; > use_sample_identifier = perf_can_sample_identifier(); > // the sample_type of cycles is different from that of sideband. > // Therefore, use_sample_identifier is set to true. > break; > } > sample_id = true; > } > > > if (sample_id) { > evlist__for_each_entry(evlist, evsel) > evsel__set_sample_id(evsel, use_sample_identifier); > // both cycles and sideband set PERF_SAMPLE_IDENTIFICATION > } > ... > } > > The comparison of the sideband event sample_type is skipped so that the sample_type of the original cycles is not changed. > > It does not seem necessary to compare the sample_type of sidebband event. It is not an actual sample event, so I'd like to confirm that. It is necessary. The sample type is used to parse ID samples that are part of e.g. MMAP events - refer perf_evsel__parse_id_sample() We could teach perf to handle dummy events differently because they do not use all the sample_type bits (only the ones in perf_evsel__parse_id_sample()) but that is probably not backward compatible. The only value in that would be to make it work without PERF_SAMPLE_ID or PERF_SAMPLE_IDENTIFIER because that would save 8-bytes per event record. Otherwise there is no benefit to prefer PERF_SAMPLE_ID over PERF_SAMPLE_IDENTIFIER except backward compatibility with some other tool that doesn't know about PERF_SAMPLE_IDENTIFIER. > > If the change is as expected and necessary, then I'll remove the patch. > > Thanks, > Yang >
Hello, On 2023/7/20 13:41, Adrian Hunter wrote: > On 18/07/23 14:32, Yang Jihong wrote: >> Hello, >> >> On 2023/7/18 18:29, Adrian Hunter wrote: >>> On 18/07/23 13:17, Yang Jihong wrote: >>>> Hello, >>>> >>>> On 2023/7/18 17:56, Adrian Hunter wrote: >>>>> On 18/07/23 12:30, Yang Jihong wrote: >>>>>> Hello, >>>>>> >>>>>> On 2023/7/17 22:41, Adrian Hunter wrote: >>>>>>> On 15/07/23 06:29, Yang Jihong wrote: >>>>>>>> The dummp event does not contain sampls data. Therefore, sample_type does >>>>>>>> not need to be checked. >>>>>>>> >>>>>>>> Currently, the sample id format of the actual sampling event may be changed >>>>>>>> after the dummy event is added. >>>>>>>> >>>>>>>> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> >>>>>>>> --- >>>>>>>> tools/perf/util/record.c | 7 +++++++ >>>>>>>> 1 file changed, 7 insertions(+) >>>>>>>> >>>>>>>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c >>>>>>>> index 9eb5c6a08999..0240be3b340f 100644 >>>>>>>> --- a/tools/perf/util/record.c >>>>>>>> +++ b/tools/perf/util/record.c >>>>>>>> @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call >>>>>>>> evlist__for_each_entry(evlist, evsel) { >>>>>>>> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >>>>>>>> continue; >>>>>>>> + >>>>>>>> + /* >>>>>>>> + * Skip the sample_type check for the dummy event >>>>>>>> + * because it does not have any samples anyway. >>>>>>>> + */ >>>>>>>> + if (evsel__is_dummy_event(evsel)) >>>>>>>> + continue; >>>>>>> >>>>>>> Sideband event records have "ID samples" so the sample type still matters. >>>>>>> >>>>>> Okay, will remove this patch in next version. >>>>>> >>>>>> Can I ask a little more about this? >>>>>> >>>>>> Use PERF_SAMPLE_IDENTIFICATION instead of PERF_SAMPLE_ID because for samples of type PERF_RECORD_SAMPLE, there may be different record formats due to different *sample_type* settings, so the fixed SAMPLE_ID location mode PERF_SAMPLE_NAME is required here. >>>>>> >>>>>> However, for the sideband event, the samples of the PERF_RECORD_SAMPLE type is not recorded (only PERF_RECORD_MMAP, PERF_RECORD_COMM, and so on). Therefore, the "use sample identifier "check can be skipped here. >>>>>> >>>>>> That's my understanding of PERF_SAMPLE_IDENTIFICATION . If there is any error, please help to correct it. >>>>>> >>>>>> *Sideband event records have "ID samples" so the sample type still matters.* >>>>>> >>>>>> Does this mean that sideband will also record samples of type PERF_RECORD_SAMPLE? What exactly is the sampling data? >>>>> >>>>> No. There are additional members as defined by struct sample_id for PERF_RECORD_MMAP: >>>>> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h?h=v6.4#n872 >>>>> >>>> I'm sorry, maybe my comments didn't make it clear. >>>> I mean, can we skip the "use_sample_identifier" check here? >>>> >>>> That is, set sample_type to *XXX|PERF_SAMPLE_ID* instead of *XXX|PERF_SAMPLE_IDENTIFICATION* >>> >>> In general, when there are different values of sample_type, the PERF_SAMPLE_ID is needed to determine which is which. >>> But PERF_SAMPLE_ID is not at a fixed position, so the sample_type is needed to find it. That is why PERF_SAMPLE_IDENTIFIER is better. >>> >>> Why do want to change it? >> >> Without this patch, we now add a system_wide tracking event and modify the sample_type of the actual sample event. >> >> For example, when we run: >> # perf record -e cycles -C 0 >> >> 1. The default sample_type of the "cycles" is IP|TID|TIME|CPU|PERIOD. >> 2. Then add a system_wide sideband event whose sample_type is IP|TID|TIME|CPU. >> 3. The two sample_types are different. >> 4. Therefore, the evlist__config adds a PERF_SAMPLE_IDENTIFICATION to both sample_types instead of PERF_SAMPLE_ID. >> >> evlist__config { >> ... >> } else if (evlist->core.nr_entries > 1) { >> // One is cycles and the other is sideband . >> struct evsel *first = evlist__first(evlist); >> >> >> evlist__for_each_entry(evlist, evsel) { >> if (evsel->core.attr.sample_type == first->core.attr.sample_type) >> continue; >> use_sample_identifier = perf_can_sample_identifier(); >> // the sample_type of cycles is different from that of sideband. >> // Therefore, use_sample_identifier is set to true. >> break; >> } >> sample_id = true; >> } >> >> >> if (sample_id) { >> evlist__for_each_entry(evlist, evsel) >> evsel__set_sample_id(evsel, use_sample_identifier); >> // both cycles and sideband set PERF_SAMPLE_IDENTIFICATION >> } >> ... >> } >> >> The comparison of the sideband event sample_type is skipped so that the sample_type of the original cycles is not changed. >> >> It does not seem necessary to compare the sample_type of sidebband event. It is not an actual sample event, so I'd like to confirm that. > > It is necessary. The sample type is used to parse ID samples > that are part of e.g. MMAP events - refer perf_evsel__parse_id_sample() > > We could teach perf to handle dummy events differently because they > do not use all the sample_type bits (only the ones in perf_evsel__parse_id_sample()) > but that is probably not backward compatible. > > The only value in that would be to make it work without > PERF_SAMPLE_ID or PERF_SAMPLE_IDENTIFIER because that would > save 8-bytes per event record. > > Otherwise there is no benefit to prefer PERF_SAMPLE_ID over > PERF_SAMPLE_IDENTIFIER except backward compatibility with > some other tool that doesn't know about PERF_SAMPLE_IDENTIFIER. > Thanks for detailed instructions, I understand, OK, will remove this patch in the next version. Thanks, Yang
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c index 9eb5c6a08999..0240be3b340f 100644 --- a/tools/perf/util/record.c +++ b/tools/perf/util/record.c @@ -128,6 +128,13 @@ void evlist__config(struct evlist *evlist, struct record_opts *opts, struct call evlist__for_each_entry(evlist, evsel) { if (evsel->core.attr.sample_type == first->core.attr.sample_type) continue; + + /* + * Skip the sample_type check for the dummy event + * because it does not have any samples anyway. + */ + if (evsel__is_dummy_event(evsel)) + continue; use_sample_identifier = perf_can_sample_identifier(); break; }