From: Ingo Molnar <mingo@elte.hu>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
minchan.kim@gmail.com
Subject: Re: [RFC mm][PATCH 2/5] percpu cached mm counter
Date: Thu, 10 Dec 2009 19:54:59 +0100 [thread overview]
Message-ID: <20091210185459.GA8697@elte.hu> (raw)
In-Reply-To: <alpine.DEB.2.00.0912101203320.5481@router.home>
* Christoph Lameter <cl@linux-foundation.org> wrote:
> On Thu, 10 Dec 2009, Ingo Molnar wrote:
>
> >
> > * Christoph Lameter <cl@linux-foundation.org> wrote:
> >
> > > On Thu, 10 Dec 2009, Ingo Molnar wrote:
> > >
> > > > No, i'm not suggesting that - i'm just suggesting that right now
> > > > MM stats are not very well suited to be exposed via perf. If we
> > > > wanted to measure/sample the information in /proc/<pid>/statm it
> > > > just wouldnt be possible. We have a few events like pagefaults
> > > > and a few tracepoints as well - but more would be possible IMO.
> > >
> > > vital MM stats are exposed via /proc/<pid> interfaces. Performance
> > > monitoring is something optional MM VM stats are used for VM
> > > decision on memory and process handling.
> >
> > You list a few facts here but what is your point?
>
> The stats are exposed already in a well defined way. [...]
They are exposed in a well defined but limited way: you cannot profile
based on those stats, you cannot measure them across a workload
transparently at precise task boundaries and you cannot trace based on
those stats.
For example, just via the simple page fault events we can today do
things like:
aldebaran:~> perf stat -e minor-faults /bin/bash -c "echo hello"
hello
Performance counter stats for '/bin/bash -c echo hello':
292 minor-faults
0.000884744 seconds time elapsed
aldebaran:~> perf record -e minor-faults -c 1 -f -g firefox
Error: cannot open display: :0
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.324 MB perf.data (~14135 samples) ]
aldebaran:~> perf report
no symbols found in /bin/sed, maybe install a debug package?
# Samples: 5312
#
# Overhead Command Shared Object Symbol
# ........ .............. ........................................ ......
#
12.54% firefox ld-2.10.90.so
[.] _dl_relocate_object
|
--- _dl_relocate_object
dl_open_worker
_dl_catch_error
dlopen_doit
0x7fffdf8c6562
0x68733d54524f5053
4.95% firefox libc-2.10.90.so
[.] __GI_memset
|
--- __GI_memset
...
I.e. 12.54% of the pagefaults in the firefox startup occur in
dlopen_doit()->_dl_catch_error()->dl_open_worker()->_dl_relocate_object()->
_dl_relocate_object() call path. 4.95% happen in __GI_memset() - etc.
> [...] Exposing via perf is outside of the scope of his work.
Please make thoughts about intelligent instrumentation solutions, and
please think "outside of the scope" of your usual routine.
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-12-10 18:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-10 7:31 [RFC mm][PATCH 0/5] per mm counter updates KAMEZAWA Hiroyuki
2009-12-10 7:33 ` [RFC mm][PATCH 1/5] mm counter cleanup KAMEZAWA Hiroyuki
2009-12-10 17:30 ` Christoph Lameter
2009-12-10 23:42 ` KAMEZAWA Hiroyuki
2009-12-11 0:07 ` Minchan Kim
2009-12-10 7:34 ` [RFC mm][PATCH 2/5] percpu cached mm counter KAMEZAWA Hiroyuki
2009-12-10 7:54 ` Ingo Molnar
2009-12-10 8:20 ` KAMEZAWA Hiroyuki
2009-12-10 8:33 ` Ingo Molnar
2009-12-10 8:42 ` KAMEZAWA Hiroyuki
2009-12-10 17:35 ` Christoph Lameter
2009-12-10 17:38 ` Ingo Molnar
2009-12-10 18:04 ` Christoph Lameter
2009-12-10 18:54 ` Ingo Molnar [this message]
2009-12-11 0:11 ` KAMEZAWA Hiroyuki
2009-12-10 17:34 ` Christoph Lameter
2009-12-10 17:51 ` Christoph Lameter
2009-12-11 0:30 ` KAMEZAWA Hiroyuki
2009-12-11 0:40 ` Minchan Kim
2009-12-11 0:51 ` KAMEZAWA Hiroyuki
2009-12-11 1:25 ` Minchan Kim
2009-12-11 1:26 ` KAMEZAWA Hiroyuki
2009-12-10 7:59 ` [RFC mm][PATCH 3/5] counting swap ents per mm KAMEZAWA Hiroyuki
2009-12-10 17:55 ` Christoph Lameter
2009-12-11 0:33 ` KAMEZAWA Hiroyuki
2009-12-11 1:07 ` Minchan Kim
2009-12-10 8:00 ` [RFC mm][PATCH 4/5] add a lowmem check function KAMEZAWA Hiroyuki
2009-12-10 17:59 ` Christoph Lameter
2009-12-11 0:39 ` KAMEZAWA Hiroyuki
2009-12-11 13:35 ` Christoph Lameter
2009-12-11 1:09 ` Minchan Kim
2009-12-10 8:01 ` [RFC mm][PATCH 5/5] counting lowmem rss per mm KAMEZAWA Hiroyuki
2009-12-11 1:12 ` Minchan Kim
2009-12-10 8:03 ` [RFC mm][PATCH 0/5] per mm counter updates KAMEZAWA Hiroyuki
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=20091210185459.GA8697@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.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