[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F0770586DED0@SHSMSX103.ccr.corp.intel.com>
Date: Thu, 7 Jan 2016 15:55:23 +0000
From: "Liang, Kan" <kan.liang@...el.com>
To: Jiri Olsa <jolsa@...hat.com>
CC: "peterz@...radead.org" <peterz@...radead.org>,
"acme@...nel.org" <acme@...nel.org>,
"eranian@...gle.com" <eranian@...gle.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"jolsa@...nel.org" <jolsa@...nel.org>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/8] perf: Add PERF_SAMPLE_PHYS_ADDR
> On Wed, Jan 06, 2016 at 06:04:30AM -0500, kan.liang@...el.com wrote:
> > From: Kan Liang <kan.liang@...el.com>
> >
> > For understanding how the workload maps to memory channels and
> > hardware behavior, it's useful to collect address maps with physical
> addresses.
> > This is not intended for detecting page sharing (which can be already
> > done using the mmap inode), but for lower level hardware behavior
> > studies.
> > Perf supports load latency/DLA which can only collect virtual addresses.
> > This patch add a new sample type PERF_SAMPLE_PHYS_ADDR to expose
> the
> > physical addresses.
> > For kernel direct mapping addresses, the patch uses virt_to_phys to
> > convert the virtual addresses from DLA to physical address.
> > For user virtual addresses, __get_user_pages_fast is used to walk the
> > pages tables for user physical address.
> > This does not work for vmalloc addresses. Right now these are not
> > resolved, but code to do that could be added.
> > For security, the physical address can only be exposed to root or
> > privileged user.
> >
> > Signed-off-by: Kan Liang <kan.liang@...el.com>
> > ---
> > arch/x86/kernel/cpu/perf_event.h | 2 +-
> > arch/x86/kernel/cpu/perf_event_intel_ds.c | 23
> +++++++++++++++++++++++
> > include/linux/perf_event.h | 3 +++
> > include/uapi/linux/perf_event.h | 4 +++-
> > kernel/events/core.c | 11 +++++++++++
> > 5 files changed, 41 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/perf_event.h
> > b/arch/x86/kernel/cpu/perf_event.h
> > index 799e6bd..164de68 100644
> > --- a/arch/x86/kernel/cpu/perf_event.h
> > +++ b/arch/x86/kernel/cpu/perf_event.h
> > @@ -90,7 +90,7 @@ struct amd_nb {
> > (PERF_SAMPLE_IP | PERF_SAMPLE_TID | PERF_SAMPLE_ADDR | \
> > PERF_SAMPLE_ID | PERF_SAMPLE_CPU |
> PERF_SAMPLE_STREAM_ID | \
> > PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER | \
> > - PERF_SAMPLE_TRANSACTION)
> > + PERF_SAMPLE_TRANSACTION | PERF_SAMPLE_PHYS_ADDR)
>
> could you please add some probe code to detect kernel support, so we get
> some sensible error message
>
I'm not quite sure what kind of probe code do you mean.
Yes, the error message below is not accurate. It could be some errors in
sample_type, read_format, branch_sample_type or something else.
Because they share the same error code -EINVAL. Perf tool cannot know
more.
I think we may print some error kernel messages when invalid attr is
detected. So the user can get more detail messages from dmesg.
Or you want me to add some extra code to detect the kernel capability
before opening event? If so, I think we may do it in separate patches.
Thanks,
Kan
> [jolsa@...va perf]$ ./perf mem -p record ls
> Error:
> The sys_perf_event_open() syscall returned with 22 (Invalid argument) for
> event (cpu/mem-loads/pp).
> /bin/dmesg may provide additional information.
> No CONFIG_PERF_EVENTS=y kernel support configured?
>
> thanks,
> jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists