From: "Liang, Kan" <kan.liang@intel.com>
To: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
CC: "mingo@redhat.com" <mingo@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "jolsa@redhat.com" <jolsa@redhat.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "eranian@google.com" <eranian@google.com>,
        "ak@linux.intel.com" <ak@linux.intel.com>,
        "mpe@ellerman.id.au" <mpe@ellerman.id.au>
Subject: RE: [PATCH V8] perf: Add PERF_SAMPLE_PHYS_ADDR
Thread-Topic: [PATCH V8] perf: Add PERF_SAMPLE_PHYS_ADDR
Thread-Index: AQHTIGE8+PToGuKVRkG/RerU6IItAKKaruWAgAAC+ICAA3fNgIABHRKAgAC7ZqCAAAAx0A==
Date: Fri, 1 Sep 2017 13:02:14 +0000
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077537A7BCF@SHSMSX103.ccr.corp.intel.com>
References: <1503967969-48278-1-git-send-email-kan.liang@intel.com>
 <5af3f1ab-b139-2c41-3218-1cba5ee3803e@linux.vnet.ibm.com>
 <20170829114553.mwd6btebikpoh6fi@hirez.programming.kicks-ass.net>
 <20170831164327.GI4831@kernel.org>
 <f006309a-9c95-6d31-1b0b-107179042c9b@linux.vnet.ibm.com>
 <37D7C6CF3E00A74B8858931C1DB2F077537A7BB6@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077537A7BB6@SHSMSX103.ccr.corp.intel.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-version: 11.0.0.116
dlp-reaction: no-action
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 2488
Lines: 68

> On Thursday 31 August 2017 10:13 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 29, 2017 at 01:45:53PM +0200, Peter Zijlstra escreveu:
> On Tue, Aug 29, 2017 at 05:05:15PM +0530, Madhavan Srinivasan wrote:
> 
> 
> On Tuesday 29 August 2017 06:22 AM, kan.liang@intel.com wrote:
> From: Kan Liang <kan.liang@intel.com>
> 
> For understanding how the workload maps to memory channels and
> hardware
> behavior, it's very important to collect address maps with physical
> addresses. For example, 3D XPoint access can only be found by filtering
> the physical address.
> 
> Add a new sample type for physical address.
> 
> perf already has a facility to collect data virtual address. This patch
> introduces a function to convert the virtual address to physical address.
> The function is quite generic and can be extended to any architecture as
> long as a virtual address is provided.
>   - For kernel direct mapping addresses, virt_to_phys is used to convert
>     the virtual addresses to physical address.
>   - For user virtual addresses, __get_user_pages_fast is used to walk the
>     pages tables for user physical address.
>   - This does not work for vmalloc addresses right now. These are not
>     resolved, but code to do that could be added.
> 
> The new sample type requires collecting the virtual address. The
> virtual address will not be output unless SAMPLE_ADDR is applied.
> 
> For security, the physical address can only be exposed to root or
> privileged user.
> 
> Tested-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> 
> You mean you tested this together with Kan's v2 perf tools patches? If
> that is so I'll add this tested-by to those patches, ok?
> Arnaldo,
> 
> No. Kernel side patch showed the link for the v1 of the perf tool side
> patchset (5 patch series) and I used that to test.
>

Thanks Maddy for the test.
Yes, the kernel patch went with user tool v1 version.
The user tool v2 version did a little modification according to the final
kernel patch. The only difference is not to mandate SAMPLE_ADDR
when SAMPLE_PHYS_ADDR.

Thanks,
Kan
 
> 
> >This patch is kernel patch.
> >The user space patch can be found here.
> >https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.spinics.net_lists_kernel_msg2587093.html&d=DwIBaQ&c=jf_iaSHv
> JObTbx-siA1ZOg&r=3f2W2m24mqGnx1C8qDsVjM_Sd89MwbaDB37IJVL-
> h7w&m=bL7qsJKf8aRpvBVr07ODZxoQhPgxffpGFgN9A4iyACw&s=R1OMYJt1sz
> qNhPZu8QQDDRCnQgHZiQzcCPzofF6FIF8&e=
> 
> Maddy
> 
> 
> 
> Thanks maddy!
>