[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <929ddd1f-dc15-079c-331d-13cc5f25a1a2@amd.com>
Date: Tue, 29 Aug 2023 17:54:23 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Yang Jihong <yangjihong1@...wei.com>, acme@...nel.org,
irogers@...gle.com, jolsa@...nel.org, namhyung@...nel.org,
adrian.hunter@...el.com
Cc: peterz@...radead.org, mingo@...hat.com, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, kan.liang@...ux.intel.com,
james.clark@....com, tmricht@...ux.ibm.com, ak@...ux.intel.com,
anshuman.khandual@....com, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org,
Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [PATCH v7 0/6] perf record: Track sideband events for all CPUs
when tracing selected CPUs
>> Number of actual samples are same ~38K. However, the perf.data file is 5x
>> bigger because of additional sideband data.
>
> Yes, if record system wide sideband data, the amount of sideband events will increase proportionally, which is expected.
>
>>
>> I'm pretty sure we don't need most of those additional data. So, thinking
>> loud, should we post-process perf.data file and filter out unnecessary data?
>>
>
> I wonder if we can add a new function in perf inject.
Ok. perf inject is one option. But shall we do it bydefault in perf-record?
It's needed only when profiling target is set of cpus, not for systemwide or
per-process mode.
> By reading perf.data and comparing tid of SAMPLE events and sideband events, we can filter out the sideband data of unmatched tasks.
Yup. But AFAIK, perf-record keeps writing to perf.data and never does post-
processing on it. So adding support for this will take a bit of effort. Not
sure if we should do it as part of this series.
Thanks,
Ravi
Powered by blists - more mailing lists