Re: [PATCH] perf: Fix probing for PERF_FLAG_FD_CLOEXEC flag

[Adrian Hunter]

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/