public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	hpa@zytor.com, paulus@samba.org, eranian@google.com,
	linux-kernel@vger.kernel.org, efault@gmx.de,
	peterz@infradead.org, namhyung@gmail.com, fweisbec@gmail.com,
	dsahern@gmail.com, tglx@linutronix.de,
	linux-tip-commits@vger.kernel.org, yrl.pp-manager.tt@hitachi.com
Subject: Re: [tip:perf/core] perf ui annotate browser: Allow toggling addr offset view
Date: Mon, 16 Apr 2012 15:25:17 +0900	[thread overview]
Message-ID: <4F8BBB4D.5090409@hitachi.com> (raw)
In-Reply-To: <20120414162851.GD22114@infradead.org>

(2012/04/15 1:28), Arnaldo Carvalho de Melo wrote:
> Em Sat, Apr 14, 2012 at 10:55:19AM +0200, Ingo Molnar escreveu:
>>
>> * Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>>
>>> Em Fri, Apr 13, 2012 at 11:30:52AM -0700, Linus Torvalds escreveu:
>>>> On Fri, Apr 13, 2012 at 11:25 AM, Linus Torvalds
>>>> <torvalds@linux-foundation.org> wrote:
>>>>>
>>>>> <kmem_cache_free>:
>>>>>    1.91 :          push   %rbp
>>>>
>>>> Oh, btw, talking about kmem_cache_free: that one uses altinstructions,
>>>> and so perf report shows the hottest instruction wrong (and I'm not
>>>> talking about "ugly"):
>>>
>>> Well, if we use Masami's disassembler we would use the actual 
>>> code as it is being used and not the original DSO that was 
>>> later patched by altinstructions.
>>
>> Key would be to use the kernel's live RAM image of instructions. 
> 
> Yeah, that is what I meant by "if we use Masami's disassembler" :-)
>  
>> I.e. we should provide a live /proc/vmlinux image in essence: a 
>> 'virtual' ELF binary image constructed out of the live kernel 
>> RAM image - with no extra RAM overhead. (Maybe with modules 
>> included in an intelligent way - although personally I don't use 
>> modules when I instrument the kernel)
>>
>> That plus the always-available /proc/kallsyms would offer rather 
>> powerful annotation already: without *any* debug info - out of 
>> box, on any Linux installation. (This was always the main 
>> advantage of /proc/profile and readprofile btw: it worked 
>> everywhere while most other profiling solutions needed a 
>> debuginfo, etc.)
>>
>> Doing /proc/vmlinux would be different from /dev/mem as it only 
>> shows the kernel RAM image, and only in a read-only fashion.

If we can ignore permissions, we can check whether the instruction
at the event address is modified or not in /dev/mem.
And that is also useful for modules. That can be done in userspace
with using setuid'd tool.

>> Default permissions of /proc/vmlinux should probably track 
>> console permissions: it should be possible to allow people 
>> sitting in front of the computer to read /proc/vmlinux, while 
>> people logged in over the network wouldn't.
>>
>> Doing such a live kernel vmlinux would have other debugging and 
>> instrumentation advantages as well: various code patching 
>> effects could be checked and observed directly.
> 
> I would say that even for userspace we would love to have such virtual
> ELF files, as code patching is become more common...

Right, if we hope to handle it correctly, we'll need to handle
all self-modifying code in kernel/user space.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

  reply	other threads:[~2012-04-16  6:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 18:07 [tip:perf/core] perf ui annotate browser: Allow toggling addr offset view tip-bot for Arnaldo Carvalho de Melo
2012-04-13 18:25 ` Linus Torvalds
2012-04-13 18:30   ` Linus Torvalds
2012-04-14  1:04     ` Arnaldo Carvalho de Melo
2012-04-14  8:55       ` Ingo Molnar
2012-04-14 16:28         ` Arnaldo Carvalho de Melo
2012-04-16  6:25           ` Masami Hiramatsu [this message]
2012-04-16 15:02             ` Linus Torvalds
2012-04-16 15:21               ` Peter Zijlstra
2012-04-18  0:43                 ` Masami Hiramatsu
2012-04-15 10:56       ` Peter Zijlstra
2012-04-14  0:59   ` Arnaldo Carvalho de Melo
2012-04-14  8:46     ` Ingo Molnar
2012-04-14 16:26       ` Arnaldo Carvalho de Melo
2012-04-15  5:29       ` Mike Galbraith
2012-04-15  6:57         ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F8BBB4D.5090409@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=acme@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=efault@gmx.de \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@gmail.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox