Re: [PATCH] perf: Fix probing for PERF_FLAG_FD_CLOEXEC flag
From: Adrian Hunter
Date: Thu Feb 19 2015 - 12:28:49 EST
On 19/02/2015 6:22 p.m., David Ahern wrote:
On 2/19/15 9:17 AM, Adrian Hunter wrote:
Yes, I am sorry it is a pain. I don't know why I didn't add a comment
to the code :-(. Using -1 for the pid is a workaround to avoid gratuitous
jump label changes. If pid=0 is used and then a system-wide trace is done
with Intel PT, there will be a jump label change shortly after the tracing
starts. That means the running code gets changed, but Intel PT decoding
has to walk the code to reconstruct the trace - so errors result. There
will always be occasional jump label changes, but this avoids one that
would otherwise always happen.
I don't understand the response. Why can't pid == getpid() (ie., pid > 0)
IIRC pid == getpid() is the same as pid = 0
> be used for this test? pid = -1 and pid = 0 are not needed. With pid > 0
> cpu value does not matter so cpu = -1 can be used. Again this is just to
> determine if the kernel supports PERF_FLAG_FD_CLOEXEC. Existence of PT
> should not be involved here.
This is about the side-effects of opening perf events. One of the side-effects
is that some jump labels get switched. For optimization reasons, there is then
a delay before they switch back. That means that a side-effect of probing the
API is that jump label changes, that otherwise would not have happened, appear
during the trace.
This is not only about Intel PT. From an abstract point of view, it is
about minimizing the disturbance to the system under test.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/