Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754130AbdFNCNU (ORCPT <rfc822;w@1wt.eu>);
        Tue, 13 Jun 2017 22:13:20 -0400
Received: from mail.kernel.org ([198.145.29.99]:38038 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753733AbdFNCNT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 13 Jun 2017 22:13:19 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4BE7623725
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org
Date: Tue, 13 Jun 2017 22:13:16 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Will Hawkins <whh8b@virginia.edu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Ftrace vs perf user page fault statistics differences
Message-ID: <20170613221316.64d46ea5@gandalf.local.home>
In-Reply-To: <CAE+MWFsBGEqe9bru3b6xWG4sSsT3wyGvfBS7uK80u+eUn9sm-A@mail.gmail.com>
References: <CAE+MWFvLvx+GRLQ4ikSb94h1jVXwmFVb-3PCzFoqC7rnOb0rvw@mail.gmail.com>
        <CAE+MWFuvAtGc0boe3arhnyoVpCpJBOsBTpk8W7Lh6r5PFE-Hmg@mail.gmail.com>
        <20170612212005.1bf8c44d@gandalf.local.home>
        <CAE+MWFv=Vu_zVt7snvKgp3vqROZ4+dgGHjc5-nD1MWcP=wgcZQ@mail.gmail.com>
        <20170613090649.2a5edb6a@gandalf.local.home>
        <CAE+MWFurcMZFG=Z-_PW1G1P5Mf+VSyzqpYqzUhbhmV_=DJgM5w@mail.gmail.com>
        <20170613160434.605fdef2@gandalf.local.home>
        <CAE+MWFsBGEqe9bru3b6xWG4sSsT3wyGvfBS7uK80u+eUn9sm-A@mail.gmail.com>
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1785
Lines: 58

On Tue, 13 Jun 2017 21:27:20 -0400
Will Hawkins <whh8b@virginia.edu> wrote:

> But, while I have your ear, I was wondering if you could direct me to
> where the page_fault_user gathers its information (when tracing) and
> where that information is formatted for printing (in trace-cmd). I'd
> really like to investigate modifying that code so that it provides
> "better" information than
> 
> address=__per_cpu_end ip=__per_cpu_end
> 
> Now that I'm into this, I want to really dig in. If you can give me a
> pointer, that would really help me get started. After that I can
> attempt to make some patches and see where it leads.
> 
> For the x86 architecture, the relevant files seem to be
> 
> mm/fault.c (with the trace_page_fault_entries function)
> 
> and
> 
> include/asm/trace/exceptions.h (where the exception class is built)

Correct.

> 
> What seems odd there is that the exception *should* be responding with
> "better" information -- address is set to the value of the cr2
> register which should contain the address of the faulting instruction.
> Perhaps I just don't understand what the symbol __per_cpu_end means.
> 
> Any information you can shed on this would be really great.

hmm, actually that looks to be translating the ip address into
functions. It shouldn't be doing that, and it doesn't do it for me with
the latest kernel and trace-cmd.

What does it give you in trace-cmd report -R ? The -R will not parse
the printk-fmt of the event format files, and just show raw numbers.

Can you give me the contents of:

 cat /sys/kernel/debug/tracing/exceptions/page_fault_user/format

?

That's how trace-cmd parses it.



> 
> Thanks again for your patience with me! I think that I now understand
> what is going on.


No problem, it's good to be curious.

-- Steve