* [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver @ 2018-01-15 4:47 Wang YanQing 2018-01-15 10:06 ` Jiri Olsa 2018-02-08 12:20 ` Jiri Olsa 0 siblings, 2 replies; 11+ messages in thread From: Wang YanQing @ 2018-01-15 4:47 UTC (permalink / raw) To: acme; +Cc: peterz, mingo, jolsa, alexander.shishkin, linux-kernel So that beautifiers wanting to resolve kernel function addresses to names can do its work, and when we use "perf report" for output of "perf kmem record", we will get kernel symbol output. Signed-off-by: Wang YanQing <udknight@gmail.com> --- tools/perf/builtin-report.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c index dd4df9a..7b65100 100644 --- a/tools/perf/builtin-report.c +++ b/tools/perf/builtin-report.c @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) report.range_num = 1; } + if (session->tevent.pevent && + pevent_set_function_resolver(session->tevent.pevent, + machine__resolve_kernel_addr, + &session->machines.host) < 0) { + pr_err("%s: failed to set libtraceevent function resolver\n", + __func__); + return -1; + } + sort__setup_elide(stdout); ret = __cmd_report(&report); -- 1.8.5.6.2.g3d8a54e.dirty ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-15 4:47 [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver Wang YanQing @ 2018-01-15 10:06 ` Jiri Olsa 2018-01-16 16:48 ` Wang YanQing 2018-02-08 12:20 ` Jiri Olsa 1 sibling, 1 reply; 11+ messages in thread From: Jiri Olsa @ 2018-01-15 10:06 UTC (permalink / raw) To: Wang YanQing, acme, peterz, mingo, alexander.shishkin, linux-kernel On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > So that beautifiers wanting to resolve kernel function addresses to > names can do its work, and when we use "perf report" for output of > "perf kmem record", we will get kernel symbol output. > > Signed-off-by: Wang YanQing <udknight@gmail.com> > --- > tools/perf/builtin-report.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > index dd4df9a..7b65100 100644 > --- a/tools/perf/builtin-report.c > +++ b/tools/perf/builtin-report.c > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > report.range_num = 1; > } > > + if (session->tevent.pevent && > + pevent_set_function_resolver(session->tevent.pevent, > + machine__resolve_kernel_addr, > + &session->machines.host) < 0) { > + pr_err("%s: failed to set libtraceevent function resolver\n", > + __func__); > + return -1; > + } why not calling the wrapper trace_event__register_resolver? jirka > + > sort__setup_elide(stdout); > > ret = __cmd_report(&report); > -- > 1.8.5.6.2.g3d8a54e.dirty > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-15 10:06 ` Jiri Olsa @ 2018-01-16 16:48 ` Wang YanQing 2018-01-18 9:43 ` Jiri Olsa 0 siblings, 1 reply; 11+ messages in thread From: Wang YanQing @ 2018-01-16 16:48 UTC (permalink / raw) To: Jiri Olsa; +Cc: acme, peterz, mingo, alexander.shishkin, linux-kernel On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote: > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > So that beautifiers wanting to resolve kernel function addresses to > > names can do its work, and when we use "perf report" for output of > > "perf kmem record", we will get kernel symbol output. > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > --- > > tools/perf/builtin-report.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > > index dd4df9a..7b65100 100644 > > --- a/tools/perf/builtin-report.c > > +++ b/tools/perf/builtin-report.c > > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > > report.range_num = 1; > > } > > > > + if (session->tevent.pevent && > > + pevent_set_function_resolver(session->tevent.pevent, > > + machine__resolve_kernel_addr, > > + &session->machines.host) < 0) { > > + pr_err("%s: failed to set libtraceevent function resolver\n", > > + __func__); > > + return -1; > > + } > > why not calling the wrapper trace_event__register_resolver? The reason is the same as builtin-script doesn't use trace_event__register_resolver, because we only use report and script to analyze offline perf.data, and there could be no tracepoints in perf.data. The wrapper trace_event__register_resolver always initialize tevent.pevent, and calling pevent_set_function_resolver which isn't necessary when there is no tracepoints in the perf.data. > > jirka > > > + > > sort__setup_elide(stdout); > > > > ret = __cmd_report(&report); > > -- > > 1.8.5.6.2.g3d8a54e.dirty > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-16 16:48 ` Wang YanQing @ 2018-01-18 9:43 ` Jiri Olsa 2018-01-18 14:22 ` Wang YanQing 0 siblings, 1 reply; 11+ messages in thread From: Jiri Olsa @ 2018-01-18 9:43 UTC (permalink / raw) To: Wang YanQing, acme, peterz, mingo, alexander.shishkin, linux-kernel On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote: > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote: > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > > So that beautifiers wanting to resolve kernel function addresses to > > > names can do its work, and when we use "perf report" for output of > > > "perf kmem record", we will get kernel symbol output. > > > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > > --- > > > tools/perf/builtin-report.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > > > index dd4df9a..7b65100 100644 > > > --- a/tools/perf/builtin-report.c > > > +++ b/tools/perf/builtin-report.c > > > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > > > report.range_num = 1; > > > } > > > > > > + if (session->tevent.pevent && > > > + pevent_set_function_resolver(session->tevent.pevent, > > > + machine__resolve_kernel_addr, > > > + &session->machines.host) < 0) { > > > + pr_err("%s: failed to set libtraceevent function resolver\n", > > > + __func__); > > > + return -1; > > > + } > > > > why not calling the wrapper trace_event__register_resolver? > The reason is the same as builtin-script doesn't use trace_event__register_resolver, > because we only use report and script to analyze offline perf.data, and there could > be no tracepoints in perf.data. hum, I missed this functionality.. so we need this even if there are no tracepoints in the perf.data? The only related interface function I could found is pevent_find_function and it seems to be called only from within traceevent library. thanks, jirka ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-18 9:43 ` Jiri Olsa @ 2018-01-18 14:22 ` Wang YanQing 2018-01-19 18:57 ` Jiri Olsa 0 siblings, 1 reply; 11+ messages in thread From: Wang YanQing @ 2018-01-18 14:22 UTC (permalink / raw) To: Jiri Olsa; +Cc: acme, peterz, mingo, alexander.shishkin, linux-kernel On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote: > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote: > > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote: > > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > > > So that beautifiers wanting to resolve kernel function addresses to > > > > names can do its work, and when we use "perf report" for output of > > > > "perf kmem record", we will get kernel symbol output. > > > > > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > > > --- > > > > tools/perf/builtin-report.c | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > > > > index dd4df9a..7b65100 100644 > > > > --- a/tools/perf/builtin-report.c > > > > +++ b/tools/perf/builtin-report.c > > > > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > > > > report.range_num = 1; > > > > } > > > > > > > > + if (session->tevent.pevent && > > > > + pevent_set_function_resolver(session->tevent.pevent, > > > > + machine__resolve_kernel_addr, > > > > + &session->machines.host) < 0) { > > > > + pr_err("%s: failed to set libtraceevent function resolver\n", > > > > + __func__); > > > > + return -1; > > > > + } > > > > > > why not calling the wrapper trace_event__register_resolver? > > The reason is the same as builtin-script doesn't use trace_event__register_resolver, > > because we only use report and script to analyze offline perf.data, and there could > > be no tracepoints in perf.data. > > hum, I missed this functionality.. so we need this even if there > are no tracepoints in the perf.data? In "perf report", when there are tracepoints in perf.data, session->tevent.pevent will be initialized in trace-event-read.c:trace_report, then "if (session->tevent.pevent" will become true, and we should calling pevent_set_function_resolver. But if we calling trace_event__register_resolver, then it will initialize tevent.pevent no matter whether there are tracepoints in perf.data. Thanks. > > The only related interface function I could found is pevent_find_function > and it seems to be called only from within traceevent library. > > thanks, > jirka ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-18 14:22 ` Wang YanQing @ 2018-01-19 18:57 ` Jiri Olsa 2018-01-21 17:25 ` Wang YanQing 0 siblings, 1 reply; 11+ messages in thread From: Jiri Olsa @ 2018-01-19 18:57 UTC (permalink / raw) To: Wang YanQing, acme, peterz, mingo, alexander.shishkin, linux-kernel On Thu, Jan 18, 2018 at 10:22:30PM +0800, Wang YanQing wrote: > On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote: > > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote: > > > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote: > > > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > > > > So that beautifiers wanting to resolve kernel function addresses to > > > > > names can do its work, and when we use "perf report" for output of > > > > > "perf kmem record", we will get kernel symbol output. > > > > > > > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > > > > --- > > > > > tools/perf/builtin-report.c | 9 +++++++++ > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > > > > > index dd4df9a..7b65100 100644 > > > > > --- a/tools/perf/builtin-report.c > > > > > +++ b/tools/perf/builtin-report.c > > > > > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > > > > > report.range_num = 1; > > > > > } > > > > > > > > > > + if (session->tevent.pevent && > > > > > + pevent_set_function_resolver(session->tevent.pevent, > > > > > + machine__resolve_kernel_addr, > > > > > + &session->machines.host) < 0) { > > > > > + pr_err("%s: failed to set libtraceevent function resolver\n", > > > > > + __func__); > > > > > + return -1; > > > > > + } > > > > > > > > why not calling the wrapper trace_event__register_resolver? > > > The reason is the same as builtin-script doesn't use trace_event__register_resolver, > > > because we only use report and script to analyze offline perf.data, and there could > > > be no tracepoints in perf.data. > > > > hum, I missed this functionality.. so we need this even if there > > are no tracepoints in the perf.data? > > In "perf report", when there are tracepoints in perf.data, session->tevent.pevent > will be initialized in trace-event-read.c:trace_report, then "if (session->tevent.pevent" > will become true, and we should calling pevent_set_function_resolver. > > But if we calling trace_event__register_resolver, then it will initialize tevent.pevent > no matter whether there are tracepoints in perf.data. ok, should we call it from perf_session__read_header then? below perf_evlist__prepare_tracepoint_events perhaps jirka ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-19 18:57 ` Jiri Olsa @ 2018-01-21 17:25 ` Wang YanQing 2018-01-23 12:41 ` Jiri Olsa 0 siblings, 1 reply; 11+ messages in thread From: Wang YanQing @ 2018-01-21 17:25 UTC (permalink / raw) To: Jiri Olsa; +Cc: acme, peterz, mingo, alexander.shishkin, linux-kernel On Fri, Jan 19, 2018 at 07:57:59PM +0100, Jiri Olsa wrote: > On Thu, Jan 18, 2018 at 10:22:30PM +0800, Wang YanQing wrote: > > On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote: > > > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote: > > > > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote: > > > > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > > > > > So that beautifiers wanting to resolve kernel function addresses to > > > > > > names can do its work, and when we use "perf report" for output of > > > > > > "perf kmem record", we will get kernel symbol output. > > > > > > > > > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > > > > > --- > > > > > > tools/perf/builtin-report.c | 9 +++++++++ > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > > > > > > index dd4df9a..7b65100 100644 > > > > > > --- a/tools/perf/builtin-report.c > > > > > > +++ b/tools/perf/builtin-report.c > > > > > > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > > > > > > report.range_num = 1; > > > > > > } > > > > > > > > > > > > + if (session->tevent.pevent && > > > > > > + pevent_set_function_resolver(session->tevent.pevent, > > > > > > + machine__resolve_kernel_addr, > > > > > > + &session->machines.host) < 0) { > > > > > > + pr_err("%s: failed to set libtraceevent function resolver\n", > > > > > > + __func__); > > > > > > + return -1; > > > > > > + } > > > > > > > > > > why not calling the wrapper trace_event__register_resolver? > > > > The reason is the same as builtin-script doesn't use trace_event__register_resolver, > > > > because we only use report and script to analyze offline perf.data, and there could > > > > be no tracepoints in perf.data. > > > > > > hum, I missed this functionality.. so we need this even if there > > > are no tracepoints in the perf.data? > > > > In "perf report", when there are tracepoints in perf.data, session->tevent.pevent > > will be initialized in trace-event-read.c:trace_report, then "if (session->tevent.pevent" > > will become true, and we should calling pevent_set_function_resolver. > > > > But if we calling trace_event__register_resolver, then it will initialize tevent.pevent > > no matter whether there are tracepoints in perf.data. > > ok, should we call it from perf_session__read_header then? > below perf_evlist__prepare_tracepoint_events perhaps No, I think we can't do it in perf_session__read_header, because perf_session__new calls perf_session__create_kernel_maps to initialize machines.host after calling perf_session__open, and pevent_set_function_resolver needs it. Although it is possible to place pevent_set_function_resolver at the tail of perf_session__new, but I don't think it is a better choice for us, because tools like "perf kmem stat" doesn't need it, "perf kmem stat" has itself way to prepare and display the symbols of callsites. I think the current calling place of pevent_set_function_resolver for "perf report" is the right place. Thanks. > jirka ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-21 17:25 ` Wang YanQing @ 2018-01-23 12:41 ` Jiri Olsa 0 siblings, 0 replies; 11+ messages in thread From: Jiri Olsa @ 2018-01-23 12:41 UTC (permalink / raw) To: Wang YanQing, acme, peterz, mingo, alexander.shishkin, linux-kernel On Mon, Jan 22, 2018 at 01:25:03AM +0800, Wang YanQing wrote: > On Fri, Jan 19, 2018 at 07:57:59PM +0100, Jiri Olsa wrote: > > On Thu, Jan 18, 2018 at 10:22:30PM +0800, Wang YanQing wrote: > > > On Thu, Jan 18, 2018 at 10:43:18AM +0100, Jiri Olsa wrote: > > > > On Wed, Jan 17, 2018 at 12:48:12AM +0800, Wang YanQing wrote: > > > > > On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote: > > > > > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > > > > > > So that beautifiers wanting to resolve kernel function addresses to > > > > > > > names can do its work, and when we use "perf report" for output of > > > > > > > "perf kmem record", we will get kernel symbol output. > > > > > > > > > > > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > > > > > > --- > > > > > > > tools/perf/builtin-report.c | 9 +++++++++ > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > > > > > > > index dd4df9a..7b65100 100644 > > > > > > > --- a/tools/perf/builtin-report.c > > > > > > > +++ b/tools/perf/builtin-report.c > > > > > > > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > > > > > > > report.range_num = 1; > > > > > > > } > > > > > > > > > > > > > > + if (session->tevent.pevent && > > > > > > > + pevent_set_function_resolver(session->tevent.pevent, > > > > > > > + machine__resolve_kernel_addr, > > > > > > > + &session->machines.host) < 0) { > > > > > > > + pr_err("%s: failed to set libtraceevent function resolver\n", > > > > > > > + __func__); > > > > > > > + return -1; > > > > > > > + } > > > > > > > > > > > > why not calling the wrapper trace_event__register_resolver? > > > > > The reason is the same as builtin-script doesn't use trace_event__register_resolver, > > > > > because we only use report and script to analyze offline perf.data, and there could > > > > > be no tracepoints in perf.data. > > > > > > > > hum, I missed this functionality.. so we need this even if there > > > > are no tracepoints in the perf.data? > > > > > > In "perf report", when there are tracepoints in perf.data, session->tevent.pevent > > > will be initialized in trace-event-read.c:trace_report, then "if (session->tevent.pevent" > > > will become true, and we should calling pevent_set_function_resolver. > > > > > > But if we calling trace_event__register_resolver, then it will initialize tevent.pevent > > > no matter whether there are tracepoints in perf.data. > > > > ok, should we call it from perf_session__read_header then? > > below perf_evlist__prepare_tracepoint_events perhaps > > No, I think we can't do it in perf_session__read_header, > because perf_session__new calls perf_session__create_kernel_maps > to initialize machines.host after calling perf_session__open, and > pevent_set_function_resolver needs it. > > Although it is possible to place pevent_set_function_resolver at > the tail of perf_session__new, but I don't think it is a better > choice for us, because tools like "perf kmem stat" doesn't need it, > "perf kmem stat" has itself way to prepare and display the symbols > of callsites. > > I think the current calling place of pevent_set_function_resolver > for "perf report" is the right place. ok jirka ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-01-15 4:47 [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver Wang YanQing 2018-01-15 10:06 ` Jiri Olsa @ 2018-02-08 12:20 ` Jiri Olsa 2018-03-06 7:36 ` Wang YanQing 1 sibling, 1 reply; 11+ messages in thread From: Jiri Olsa @ 2018-02-08 12:20 UTC (permalink / raw) To: Wang YanQing, acme, peterz, mingo, alexander.shishkin, linux-kernel On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > So that beautifiers wanting to resolve kernel function addresses to > names can do its work, and when we use "perf report" for output of > "perf kmem record", we will get kernel symbol output. > > Signed-off-by: Wang YanQing <udknight@gmail.com> Acked-by: Jiri Olsa <jolsa@kernel.org> thanks, jirka > --- > tools/perf/builtin-report.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c > index dd4df9a..7b65100 100644 > --- a/tools/perf/builtin-report.c > +++ b/tools/perf/builtin-report.c > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv) > report.range_num = 1; > } > > + if (session->tevent.pevent && > + pevent_set_function_resolver(session->tevent.pevent, > + machine__resolve_kernel_addr, > + &session->machines.host) < 0) { > + pr_err("%s: failed to set libtraceevent function resolver\n", > + __func__); > + return -1; > + } > + > sort__setup_elide(stdout); > > ret = __cmd_report(&report); > -- > 1.8.5.6.2.g3d8a54e.dirty > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-02-08 12:20 ` Jiri Olsa @ 2018-03-06 7:36 ` Wang YanQing 2018-03-06 14:01 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 11+ messages in thread From: Wang YanQing @ 2018-03-06 7:36 UTC (permalink / raw) To: acme; +Cc: jolsa, peterz, mingo, alexander.shishkin, linux-kernel On Thu, Feb 08, 2018 at 01:20:31PM +0100, Jiri Olsa wrote: > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > So that beautifiers wanting to resolve kernel function addresses to > > names can do its work, and when we use "perf report" for output of > > "perf kmem record", we will get kernel symbol output. > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > Acked-by: Jiri Olsa <jolsa@kernel.org> Hi! Arnaldo Carvalho de Melo What is the status of this patch now? Does the patch sanked to the bottom of your mailbox? Thanks! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver 2018-03-06 7:36 ` Wang YanQing @ 2018-03-06 14:01 ` Arnaldo Carvalho de Melo 0 siblings, 0 replies; 11+ messages in thread From: Arnaldo Carvalho de Melo @ 2018-03-06 14:01 UTC (permalink / raw) To: Wang YanQing, jolsa, peterz, mingo, alexander.shishkin, linux-kernel Em Tue, Mar 06, 2018 at 03:36:58PM +0800, Wang YanQing escreveu: > On Thu, Feb 08, 2018 at 01:20:31PM +0100, Jiri Olsa wrote: > > On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote: > > > So that beautifiers wanting to resolve kernel function addresses to > > > names can do its work, and when we use "perf report" for output of > > > "perf kmem record", we will get kernel symbol output. > > > > > > Signed-off-by: Wang YanQing <udknight@gmail.com> > > > > Acked-by: Jiri Olsa <jolsa@kernel.org> > > Hi! Arnaldo Carvalho de Melo > > What is the status of this patch now? > Does the patch sanked to the bottom of your mailbox? It looks ok, but you forgot to add a before and after output of tools affected by the patch. Reading the patch one can try and figure out how to test your patch, but if you show how the output is changed, providing the exact command line used to produce the output, then you will make it easier for reviewers to reproduce your results, testing your patch. I try to do this for every patch, so it all adds up, please help me with reviewing your patch :-) - Arnaldo ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-03-06 14:01 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-15 4:47 [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver Wang YanQing 2018-01-15 10:06 ` Jiri Olsa 2018-01-16 16:48 ` Wang YanQing 2018-01-18 9:43 ` Jiri Olsa 2018-01-18 14:22 ` Wang YanQing 2018-01-19 18:57 ` Jiri Olsa 2018-01-21 17:25 ` Wang YanQing 2018-01-23 12:41 ` Jiri Olsa 2018-02-08 12:20 ` Jiri Olsa 2018-03-06 7:36 ` Wang YanQing 2018-03-06 14:01 ` Arnaldo Carvalho de Melo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.