[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-5=fXXykcwjXjd+W=8Eez79JhmuKhf1Z-1R_8+AD4XdY4a8A@mail.gmail.com>
Date: Mon, 29 May 2023 23:54:37 -0700
From: Ian Rogers <irogers@...gle.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
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>,
"Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
"Steven Rostedt (Google)" <rostedt@...dmis.org>,
Ross Zwisler <zwisler@...omium.org>,
Leo Yan <leo.yan@...aro.org>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
Yang Jihong <yangjihong1@...wei.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Ravi Bangoria <ravi.bangoria@....com>,
Sean Christopherson <seanjc@...gle.com>,
K Prateek Nayak <kprateek.nayak@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v2 00/16] Address some perf memory/data size issues
On Mon, May 29, 2023 at 9:57 PM Andi Kleen <ak@...ux.intel.com> wrote:
>
>
> FWIW I think the whole patchkit could be replaced with a one liner
> that disables THP for the BSS segment. I suspect that would be roughly
> equivalent for memory consumption because 4K pages that are never
> touched would never be allocated.
>
> -Andi
So, it is worth reading some of the comments on the code to see why a
wider clean up is worth it:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/util/path.c?h=perf-tools#n7
"It's obviously not thread-safe. Sue me."
(a comment stemming back to the git origins of the code base)
BSS won't count toward file size, which the patches were primarily
going after - but checking the size numbers I have miscalculated from
reading size's output that I'm not familiar with. The numbers are
still improved, but I just see a 37kb saving, with 5kb more in
.rodata. Something but not much. .data.rel.ro is larger, which imo is
good, but those pages will still be dirtied so a mute point wrt file
size and memory overhead.
For huge pages I thought it was correct that things are aligned by max
page size which I thought on x86-64 was 2MB, so I tried:
EXTRA_LDFLAGS="-z max-page-size=4096"
but it made no difference to anything, and with:
EXTRA_CFLAGS="-Wl,-z,max-page-size=4096"
EXTRA_CXXFLAGS="-Wl,-z,max-page-size=4096"
file size just got worse.
Thanks,
Ian
Powered by blists - more mailing lists