From: Andrew Morton <akpm@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
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 13:53:15 -0700 [thread overview]
Message-ID: <20090804135315.b2678e11.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090804203526.GA8699@elte.hu>
On Tue, 4 Aug 2009 22:35:26 +0200
Ingo Molnar <mingo@elte.hu> wrote:
> 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.
OK, that would be useful. What does the output look like?
In what way is it superior to existing ways of finding leaks?
> 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.
That's bad. Is there really no way in which we can consolidate _any_
of that infrastructure? We just pile in new stuff alongside the old?
The worst part is needing two unrelated sets of userspace tools to
access basically-identical things.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
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 13:53:15 -0700 [thread overview]
Message-ID: <20090804135315.b2678e11.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090804203526.GA8699@elte.hu>
On Tue, 4 Aug 2009 22:35:26 +0200
Ingo Molnar <mingo@elte.hu> wrote:
> 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.
OK, that would be useful. What does the output look like?
In what way is it superior to existing ways of finding leaks?
> 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.
That's bad. Is there really no way in which we can consolidate _any_
of that infrastructure? We just pile in new stuff alongside the old?
The worst part is needing two unrelated sets of userspace tools to
access basically-identical things.
--
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:55 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
2009-08-04 20:35 ` Ingo Molnar
2009-08-04 20:53 ` Andrew Morton [this message]
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=20090804135315.b2678e11.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--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=mingo@elte.hu \
--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.