All of lore.kernel.org
 help / color / mirror / Atom feed
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:18:18 -0700	[thread overview]
Message-ID: <20090804131818.ee5d4696.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090804195717.GA5998@elte.hu>

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.

As usual, we're adding tracepoints because we feel we must add
tracepoints, not because anyone has a need for the data which they
gather.

There is some benefit in providing MM developers with some code which
they can copy-n-paste for their day-to-day activity.  But as I said,
they can do that with vmstat too.


If we can get rid of vmstat all together (and meminfo) and replace all
that with common infrastructure then that would be a good cleanup.  But
if we end up leaving vmstat and meminfo in place and then adding
_another_ statistic gathering mechanism in parallel then we haven't
cleaned anything up at all - it just gets worse.


I don't really oppose the patches - they're small.  But they seem
rather useless too.

It would be nice to at least partially remove the vmstat/meminfo
infrastructure but I don't think we can do that?

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:18:18 -0700	[thread overview]
Message-ID: <20090804131818.ee5d4696.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090804195717.GA5998@elte.hu>

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.

As usual, we're adding tracepoints because we feel we must add
tracepoints, not because anyone has a need for the data which they
gather.

There is some benefit in providing MM developers with some code which
they can copy-n-paste for their day-to-day activity.  But as I said,
they can do that with vmstat too.


If we can get rid of vmstat all together (and meminfo) and replace all
that with common infrastructure then that would be a good cleanup.  But
if we end up leaving vmstat and meminfo in place and then adding
_another_ statistic gathering mechanism in parallel then we haven't
cleaned anything up at all - it just gets worse.


I don't really oppose the patches - they're small.  But they seem
rather useless too.

It would be nice to at least partially remove the vmstat/meminfo
infrastructure but I don't think we can do that?

--
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 20:19 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 [this message]
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
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=20090804131818.ee5d4696.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.