[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231012091537.GM6307@noisy.programming.kicks-ass.net>
Date: Thu, 12 Oct 2023 11:15:37 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Stephane Eranian <eranian@...gle.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
linux-toolchains@...r.kernel.org,
linux-trace-devel@...r.kernel.org,
Ben Woodard <woodard@...hat.com>,
Joe Mario <jmario@...hat.com>,
Kees Cook <keescook@...omium.org>,
David Blaikie <blaikie@...gle.com>,
Xu Liu <xliuprof@...gle.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [RFC 00/48] perf tools: Introduce data type profiling (v1)
On Wed, Oct 11, 2023 at 08:50:23PM -0700, Namhyung Kim wrote:
> Actually there's a performance issue about getting disassembly from the
> objdump for kernel. On my system, GNU objdump was really slower than the
> one from LLVM for some reason so I had to pass the following option for
> each perf report and perf annotate.
>
> $ sudo perf report --objdump=llvm-objdump ...
>
> # To save it in the config file and drop the command line option
> $ sudo perf config annotate.objdump=llvm-objdump
>
> Even with this change, still the most processing time was spent on the
> objdump to get the disassembly. It'd be nice if we can get the result
> without using objdump at all.
So the kernel has an instruction decoder, all we need is something that
can pretty print the result. IIRC Masami had an early version of that
somewhere.
With those bits, and some basic ELF parsing (find in objtool for
instance) you can implement most of objdump yourself.
Powered by blists - more mailing lists