From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: penberg@cs.helsinki.fi, a.p.zijlstra@chello.nl,
fweisbec@gmail.com, rostedt@goodmis.org, mel@csn.ul.ie,
lwoodman@redhat.com, riel@redhat.com, peterz@infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events
Date: Tue, 4 Aug 2009 22:35:26 +0200 [thread overview]
Message-ID: <20090804203526.GA8699@elte.hu> (raw)
In-Reply-To: <20090804131818.ee5d4696.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 4 Aug 2009 21:57:17 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > Let me demonstrate these features in action (i've applied the
> > patches for testing to -tip):
>
> So? The fact that certain things can be done doesn't mean that
> there's a demand for them, nor that anyone will _use_ this stuff.
c'mon Andrew ...
Did you never want to see whether firefox is leaking [any sort of]
memory, and if yes, on what callsites? Try something like on an
already running firefox context:
perf stat -e kmem:mm_page_alloc \
-e kmem:mm_pagevec_free \
-e kmem:mm_page_free_direct \
-p $(pidof firefox-bin) sleep 10
... and "perf record" for the specific callsites.
this perf stuff is immensely flexible and a very unixish
abstraction. The perf.data contains timestamped trace entries of
page allocations and freeing done.
[...]
> It would be nice to at least partially remove the vmstat/meminfo
> infrastructure but I don't think we can do that?
at least meminfo is an ABI for sure - vmstat too really.
But we can stop adding new fields into obsolete, inflexible and
clearly deficient interfaces, and we can standardize new
instrumentation to use modern instrumentation facilities - i.e.
tracepoints and perfcounters.
I'm not saying to put a tracepoint on every second line of the
kernel, but obviously Mel and Rik wanted this kind of info because
they found it useful in practice.
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: penberg@cs.helsinki.fi, a.p.zijlstra@chello.nl,
fweisbec@gmail.com, rostedt@goodmis.org, mel@csn.ul.ie,
lwoodman@redhat.com, riel@redhat.com, peterz@infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events
Date: Tue, 4 Aug 2009 22:35:26 +0200 [thread overview]
Message-ID: <20090804203526.GA8699@elte.hu> (raw)
In-Reply-To: <20090804131818.ee5d4696.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 4 Aug 2009 21:57:17 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > Let me demonstrate these features in action (i've applied the
> > patches for testing to -tip):
>
> So? The fact that certain things can be done doesn't mean that
> there's a demand for them, nor that anyone will _use_ this stuff.
c'mon Andrew ...
Did you never want to see whether firefox is leaking [any sort of]
memory, and if yes, on what callsites? Try something like on an
already running firefox context:
perf stat -e kmem:mm_page_alloc \
-e kmem:mm_pagevec_free \
-e kmem:mm_page_free_direct \
-p $(pidof firefox-bin) sleep 10
... and "perf record" for the specific callsites.
this perf stuff is immensely flexible and a very unixish
abstraction. The perf.data contains timestamped trace entries of
page allocations and freeing done.
[...]
> It would be nice to at least partially remove the vmstat/meminfo
> infrastructure but I don't think we can do that?
at least meminfo is an ABI for sure - vmstat too really.
But we can stop adding new fields into obsolete, inflexible and
clearly deficient interfaces, and we can standardize new
instrumentation to use modern instrumentation facilities - i.e.
tracepoints and perfcounters.
I'm not saying to put a tracepoint on every second line of the
kernel, but obviously Mel and Rik wanted this kind of info because
they found it useful in practice.
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-08-04 20:36 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-04 18:12 [PATCH 0/4] Add some trace events for the page allocator v3 Mel Gorman
2009-08-04 18:12 ` Mel Gorman
2009-08-04 18:12 ` [PATCH 1/4] tracing, page-allocator: Add trace events for page allocation and page freeing Mel Gorman
2009-08-04 18:12 ` Mel Gorman
2009-08-05 9:13 ` KOSAKI Motohiro
2009-08-05 9:13 ` KOSAKI Motohiro
2009-08-05 9:40 ` Mel Gorman
2009-08-05 9:40 ` Mel Gorman
2009-08-07 1:17 ` KOSAKI Motohiro
2009-08-07 1:17 ` KOSAKI Motohiro
2009-08-07 17:31 ` Mel Gorman
2009-08-07 17:31 ` Mel Gorman
2009-08-08 5:44 ` KOSAKI Motohiro
2009-08-08 5:44 ` KOSAKI Motohiro
2009-08-04 18:12 ` [PATCH 2/4] tracing, mm: Add trace events for anti-fragmentation falling back to other migratetypes Mel Gorman
2009-08-04 18:12 ` Mel Gorman
2009-08-05 9:26 ` KOSAKI Motohiro
2009-08-05 9:26 ` KOSAKI Motohiro
2009-08-04 18:12 ` [PATCH 3/4] tracing, page-allocator: Add trace event for page traffic related to the buddy lists Mel Gorman
2009-08-04 18:12 ` Mel Gorman
2009-08-05 9:24 ` KOSAKI Motohiro
2009-08-05 9:24 ` KOSAKI Motohiro
2009-08-05 9:43 ` Mel Gorman
2009-08-05 9:43 ` Mel Gorman
2009-08-07 1:03 ` KOSAKI Motohiro
2009-08-07 1:03 ` KOSAKI Motohiro
2009-08-04 18:12 ` [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events Mel Gorman
2009-08-04 18:12 ` Mel Gorman
2009-08-04 18:22 ` Andrew Morton
2009-08-04 18:22 ` Andrew Morton
2009-08-04 18:27 ` Rik van Riel
2009-08-04 18:27 ` Rik van Riel
2009-08-04 19:13 ` Andrew Morton
2009-08-04 19:13 ` Andrew Morton
2009-08-04 20:48 ` Mel Gorman
2009-08-04 20:48 ` Mel Gorman
2009-08-05 7:41 ` Ingo Molnar
2009-08-05 7:41 ` Ingo Molnar
2009-08-05 9:07 ` Mel Gorman
2009-08-05 9:07 ` Mel Gorman
2009-08-05 9:16 ` Ingo Molnar
2009-08-05 9:16 ` Ingo Molnar
2009-08-05 10:27 ` Johannes Weiner
2009-08-05 10:27 ` Johannes Weiner
2009-08-06 15:48 ` Mel Gorman
2009-08-06 15:48 ` Mel Gorman
2009-08-05 14:53 ` Larry Woodman
2009-08-05 14:53 ` Larry Woodman
2009-08-06 15:54 ` Mel Gorman
2009-08-06 15:54 ` Mel Gorman
2009-08-04 19:57 ` Ingo Molnar
2009-08-04 19:57 ` Ingo Molnar
2009-08-04 20:18 ` Andrew Morton
2009-08-04 20:18 ` Andrew Morton
2009-08-04 20:35 ` Ingo Molnar [this message]
2009-08-04 20:35 ` Ingo Molnar
2009-08-04 20:53 ` Andrew Morton
2009-08-04 20:53 ` Andrew Morton
2009-08-05 7:53 ` Ingo Molnar
2009-08-05 7:53 ` Ingo Molnar
2009-08-05 13:04 ` Peter Zijlstra
2009-08-05 13:04 ` Peter Zijlstra
2009-08-05 15:07 ` Valdis.Kletnieks
2009-08-05 14:53 ` Valdis.Kletnieks
2009-08-05 18:53 ` perf: "Longum est iter per praecepta, breve et efficax per exempla" Carlos R. Mafra
2009-08-06 7:08 ` Pekka Enberg
2009-08-06 7:35 ` Ingo Molnar
2009-08-06 8:38 ` Carlos R. Mafra
2009-08-06 8:32 ` Carlos R. Mafra
2009-08-06 9:10 ` Ingo Molnar
2009-08-08 12:37 ` [tip:perfcounters/urgent] " tip-bot for Carlos R. Mafra
2009-08-09 11:11 ` [tip:perfcounters/core] " tip-bot for Carlos R. Mafra
2009-08-06 15:50 ` [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events Mel Gorman
2009-08-06 15:50 ` Mel Gorman
2009-08-05 3:07 ` KOSAKI Motohiro
2009-08-05 3:07 ` KOSAKI Motohiro
-- strict thread matches above, loose matches on Subject: below --
2009-07-29 21:05 [RFC PATCH 0/4] Add some trace events for the page allocator v2 Mel Gorman
2009-07-29 21:05 ` [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events Mel Gorman
2009-07-29 21:05 ` Mel Gorman
2009-07-30 13:45 ` Rik van Riel
2009-07-30 13:45 ` Rik van Riel
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=20090804203526.GA8699@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@redhat.com \
--cc=mel@csn.ul.ie \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
/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.