Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <a37ede61-c607-4fcf-2be4-12b83cdf0d7e@linux.intel.com>
Date:   Tue, 26 Oct 2021 10:03:02 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: Re: [PATCH V2 3/6] perf intel-pt: Support itrace A option to
 approximate IPC
Content-Language: en-US
To:     Adrian Hunter <adrian.hunter@intel.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>
Cc:     Jiri Olsa <jolsa@redhat.com>, linux-kernel@vger.kernel.org
References: <20211026090152.357591-1-adrian.hunter@intel.com>
 <20211026090152.357591-4-adrian.hunter@intel.com>
From:   Andi Kleen <ak@linux.intel.com>
In-Reply-To: <20211026090152.357591-4-adrian.hunter@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/26/2021 2:01 AM, Adrian Hunter wrote:
> Normally, for cycle-acccurate mode, IPC values are an exact number of
> instructions and cycles. Due to the granularity of timestamps, that happens
> only when a CYC packet correlates to the event.
>
> Support the itrace 'A' option, to use instead, the number of cycles
> associated with the current timestamp. This provides IPC information for
> every change of timestamp, but at the expense of accuracy.

Can you expand a bit what exactly the accuracy loss it?

Would be good to describe that in the manpage too.