linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Rik van Riel <riel@redhat.com>
Cc: mel@csn.ul.ie, lwoodman@redhat.com, mingo@elte.hu,
	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 12:13:32 -0700	[thread overview]
Message-ID: <20090804121332.46df33a7.akpm@linux-foundation.org> (raw)
In-Reply-To: <4A787D84.2030207@redhat.com>

On Tue, 04 Aug 2009 14:27:16 -0400
Rik van Riel <riel@redhat.com> wrote:

> Andrew Morton wrote:
> > On Tue,  4 Aug 2009 19:12:26 +0100 Mel Gorman <mel@csn.ul.ie> wrote:
> > 
> >> This patch adds a simple post-processing script for the page-allocator-related
> >> trace events. It can be used to give an indication of who the most
> >> allocator-intensive processes are and how often the zone lock was taken
> >> during the tracing period. Example output looks like
> >>
> >> find-2840
> >>  o pages allocd            = 1877
> >>  o pages allocd under lock = 1817
> >>  o pages freed directly    = 9
> >>  o pcpu refills            = 1078
> >>  o migrate fallbacks       = 48
> >>    - fragmentation causing = 48
> >>      - severe              = 46
> >>      - moderate            = 2
> >>    - changed migratetype   = 7
> > 
> > The usual way of accumulating and presenting such measurements is via
> > /proc/vmstat.  How do we justify adding a completely new and different
> > way of doing something which we already do?
> 
> Mel's tracing is more akin to BSD process accounting,
> where these statistics are kept on a per-process basis.

Is that useful?  Any time I've wanted to find out things like this, I
just don't run other stuff on the machine at the same time.

Maybe there are some scenarios where it's useful to filter out other
processes, but are those scenarios sufficiently important to warrant
creation of separate machinery like this?

> Nothing in /proc allows us to see statistics on a per
> process basis on process exit.

Can this script be used to monitor the process while it's still running?



Also, we have a counter for "moderate fragmentation causing migrate
fallbacks".  There must be hundreds of MM statistics which can be
accumulated once we get down to this level of detail.  Why choose these
nine?


Is there a plan to add the rest later on?


Or are these nine more a proof-of-concept demonstration-code thing?  If
so, is it expected that developers will do an ad-hoc copy-n-paste to
solve a particular short-term problem and will then toss the tracepoint
away?  I guess that could be useful, although you can do the same with
vmstat.

--
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>

  reply	other threads:[~2009-08-04 18:45 UTC|newest]

Thread overview: 37+ 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 ` [PATCH 1/4] tracing, page-allocator: Add trace events for page allocation and page freeing Mel Gorman
2009-08-05  9:13   ` KOSAKI Motohiro
2009-08-05  9:40     ` Mel Gorman
2009-08-07  1:17       ` KOSAKI Motohiro
2009-08-07 17:31         ` Mel Gorman
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-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-05  9:24   ` KOSAKI Motohiro
2009-08-05  9:43     ` Mel Gorman
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:22   ` Andrew Morton
2009-08-04 18:27     ` Rik van Riel
2009-08-04 19:13       ` Andrew Morton [this message]
2009-08-04 20:48         ` Mel Gorman
2009-08-05  7:41           ` Ingo Molnar
2009-08-05  9:07             ` Mel Gorman
2009-08-05  9:16               ` Ingo Molnar
2009-08-05 10:27               ` Johannes Weiner
2009-08-06 15:48                 ` Mel Gorman
2009-08-05 14:53           ` Larry Woodman
2009-08-06 15:54             ` Mel Gorman
2009-08-04 19:57     ` Ingo Molnar
2009-08-04 20:18       ` Andrew Morton
2009-08-04 20:35         ` Ingo Molnar
2009-08-04 20:53           ` Andrew Morton
2009-08-05  7:53             ` Ingo Molnar
2009-08-05 13:04           ` Peter Zijlstra
2009-08-05 15:07         ` Valdis.Kletnieks
2009-08-05 14:53       ` Valdis.Kletnieks
2009-08-06 15:50       ` Mel Gorman
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-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=20090804121332.46df33a7.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --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=peterz@infradead.org \
    --cc=riel@redhat.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;
as well as URLs for NNTP newsgroup(s).