Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753287AbbBSR2q (ORCPT ); Thu, 19 Feb 2015 12:28:46 -0500 Received: from mga11.intel.com ([192.55.52.93]:29524 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752089AbbBSR2p (ORCPT ); Thu, 19 Feb 2015 12:28:45 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,609,1418112000"; d="scan'208";a="668711604" Message-ID: <54E61D49.9000605@intel.com> Date: Thu, 19 Feb 2015 19:28:41 +0200 From: Adrian Hunter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Ahern , David Ahern , acme@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] perf: Fix probing for PERF_FLAG_FD_CLOEXEC flag References: <1424304072-91955-1-git-send-email-david.ahern@oracle.com> <54E58B64.9010902@intel.com> <54E5F963.50200@gmail.com> <54E60CA0.6020001@intel.com> <54E60DB5.5070509@oracle.com> In-Reply-To: <54E60DB5.5070509@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1744 Lines: 35 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/