All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.