When checking the fields in the PERF_SAMPLE_DATA_SRC type samples
you need to shift the masks before doing the compare.
Although the value you are checking (perf_mem_data_src) is
specified as a bitfield so this might all fall apart if trying
to access the field in a cross-endian way. The Power people
were working on this issue, not sure if they resolved it.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This clarifies the PERF_SAMPLE_STACK_USER section.
I found these issue while implementing some code that uses
the option. The important change is fixing the name of the
sample_stack_user parameter, the rest is just some wording
fixes and minor clarifications.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Clarify the reasons for EACCES and EPERM errors.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Expand the perf_event_open.2 ERRORS section to be more comprehensive.
These were determined both by code inspection and by writing a large
number of test programs.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The Linux 3.14 release adds support for the PERF_FLAG_FD_CLOEXEC
flag.
The wording is based on the description in kernel commit
a21b0b354d4ac39be691f51c53562e2c24443d9e
by Yann Droneaud.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Linux 3.14 (in commit bad7192b842c83e580747ca57104dd51fe08c223)
changes the perf_event PERF_EVENT_IOC_PERIOD ioctl() behavior
on all architectures to update immediately, to match the behavior
found on ARM.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The following patch adds descriptions of the new perf_event_open.2
PERF_SAMPLE_TRANSACTION sample type as added in Linux 3.13.
The descriptions are based on information provided by Andi Kleen,
both in the e-mail
[PATCH 1/6] perf, core: Add generic transaction flags v5
sent to the linux-kernel list as well as an e-mail
[PATCH] Document transaction flags in perf_event_open manpage
sent to the linux-man list.
The implementation is based heavily on the Intel Haswell
processor. Documentation can be found at this page:
http://software.intel.com/en-us/blogs/2013/05/03/intelr-transactional-synchronization-extensions-intelr-tsx-profiling-with-linux-0
as well as in section 18.11.5.1 of volume 3 of the
Intel 64 and IA-32 Architecture Software Developer's Manual.
Also, someone with better manpage formatting skills than I have
should probably investigate why I can't get the last line of
the change to properly tab-align with the .I transaction
heading.
Cowritten-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Clarify the perf_event_open behavior with respect to the disabled
bit and creating event groups.
Reported-by: Sudhanshu Goswami <Sudhanshu.Goswami@emc.com>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Warn that using the perf_event_open "exclusive" bit, while it might seem
like a good idea, might lead to all 0 results in some common usage cases.
Reported-by: Sudhanshu Goswami <Sudhanshu.Goswami@emc.com>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here's an updated version of [David Ahern's] patch that
expands the "mmap" definition as well as that of "mmap_data".
Also some manpage related formatting improvements from the
original patch.
Link: https://lkml.org/lkml/2013/11/11/505
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch attempts to clarify the pid and cpu options to
perf_event_open().
It does two things:
1. Tries to make clear that the "pid" argument can mean
process *or* thread. This is made confusing by
how Linux uses the terms mostly interchangeably.
2. The cpu/pid documentation was confusing because of
how the parameters are interdependent. Since there
are only 6 possible combinations I broke out the
possibilities into a table.
Reported-by: Manuel Selva <selva.manuel@gmail.com>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Vince Weaver