[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZWUSNLmApMByu94B@kernel.org>
Date: Mon, 27 Nov 2023 19:03:32 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Nick Terrell <terrelln@...com>,
Kan Liang <kan.liang@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>,
Kajol Jain <kjain@...ux.ibm.com>,
Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
Huacai Chen <chenhuacai@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Vincent Whitchurch <vincent.whitchurch@...s.com>,
"Steinar H. Gunderson" <sesse@...gle.com>,
Liam Howlett <liam.howlett@...cle.com>,
Miguel Ojeda <ojeda@...nel.org>,
Colin Ian King <colin.i.king@...il.com>,
Dmitrii Dolgov <9erthalion6@...il.com>,
Yang Jihong <yangjihong1@...wei.com>,
Ming Wang <wangming01@...ngson.cn>,
James Clark <james.clark@....com>,
K Prateek Nayak <kprateek.nayak@....com>,
Sean Christopherson <seanjc@...gle.com>,
Leo Yan <leo.yan@...aro.org>,
Ravi Bangoria <ravi.bangoria@....com>,
German Gomez <german.gomez@....com>,
Changbin Du <changbin.du@...wei.com>,
Paolo Bonzini <pbonzini@...hat.com>, Li Dong <lidong@...o.com>,
Sandipan Das <sandipan.das@....com>,
liuwenyu <liuwenyu7@...wei.com>, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v4 10/53] perf record: Be lazier in allocating lost
samples buffer
Em Thu, Nov 02, 2023 at 10:56:52AM -0700, Ian Rogers escreveu:
> Wait until a lost sample occurs to allocate the lost samples buffer,
> often the buffer isn't necessary. This saves a 64kb allocation and
> 5.3kb of peak memory consumption.
>
> Signed-off-by: Ian Rogers <irogers@...gle.com>
> ---
> tools/perf/builtin-record.c | 29 +++++++++++++++++++----------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 9b4f3805ca92..b6c8c1371b39 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -1924,21 +1924,13 @@ static void __record__save_lost_samples(struct record *rec, struct evsel *evsel,
> static void record__read_lost_samples(struct record *rec)
> {
> struct perf_session *session = rec->session;
> - struct perf_record_lost_samples *lost;
> + struct perf_record_lost_samples *lost = NULL;
> struct evsel *evsel;
>
> /* there was an error during record__open */
> if (session->evlist == NULL)
> return;
>
> - lost = zalloc(PERF_SAMPLE_MAX_SIZE);
> - if (lost == NULL) {
> - pr_debug("Memory allocation failed\n");
> - return;
> - }
Shouldn't we take the time here and instead improve this error message
and then propagate the error?
For instance, we may want to still get some perf.data file without these
records but inform the user at this point how many records were lost
(count.lost)?
- Arnaldo
> -
> - lost->header.type = PERF_RECORD_LOST_SAMPLES;
> -
> evlist__for_each_entry(session->evlist, evsel) {
> struct xyarray *xy = evsel->core.sample_id;
> u64 lost_count;
> @@ -1961,6 +1953,14 @@ static void record__read_lost_samples(struct record *rec)
> }
>
> if (count.lost) {
> + if (!lost) {
> + lost = zalloc(PERF_SAMPLE_MAX_SIZE);
> + if (!lost) {
> + pr_debug("Memory allocation failed\n");
> + return;
> + }
> + lost->header.type = PERF_RECORD_LOST_SAMPLES;
> + }
> __record__save_lost_samples(rec, evsel, lost,
> x, y, count.lost, 0);
> }
> @@ -1968,9 +1968,18 @@ static void record__read_lost_samples(struct record *rec)
> }
>
> lost_count = perf_bpf_filter__lost_count(evsel);
> - if (lost_count)
> + if (lost_count) {
> + if (!lost) {
> + lost = zalloc(PERF_SAMPLE_MAX_SIZE);
> + if (!lost) {
> + pr_debug("Memory allocation failed\n");
> + return;
> + }
> + lost->header.type = PERF_RECORD_LOST_SAMPLES;
> + }
> __record__save_lost_samples(rec, evsel, lost, 0, 0, lost_count,
> PERF_RECORD_MISC_LOST_SAMPLES_BPF);
> + }
> }
> out:
> free(lost);
> --
> 2.42.0.869.gea05f2083d-goog
>
--
- Arnaldo
Powered by blists - more mailing lists