linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: "Larry Woodman" <lwoodman@redhat.com>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Fr馘駻ic Weisbecker" <fweisbec@gmail.com>,
	"Li Zefan" <lizf@cn.fujitsu.com>,
	"Pekka Enberg" <penberg@cs.helsinki.fi>,
	eduard.munteanu@linux360.ro, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, rostedt@goodmis.org
Subject: Re: [Patch] mm tracepoints update - use case.
Date: Mon, 15 Jun 2009 14:26:37 -0400	[thread overview]
Message-ID: <4A36925D.4090000@redhat.com> (raw)
In-Reply-To: <20090423092933.F6E9.A69D9226@jp.fujitsu.com>

KOSAKI Motohiro wrote:
>> On Wed, 2009-04-22 at 08:07 -0400, Larry Woodman wrote:

>> Attached is an example of what the mm tracepoints can be used for:
> 
> I have some comment.
> 
> 1. Yes, current zone_reclaim have strange behavior. I plan to fix
>    some bug-like bahavior.
> 2. your scenario only use the information of "zone_reclaim called".
>    function tracer already provide it.
> 3. but yes, you are going to proper direction. we definitely need
>    some fine grained tracepoint in this area. we are welcome to you.
>    but in my personal feeling, your tracepoint have worthless argument
>    a lot. we need more good information.
>    I think I can help you in this area. I hope to work together.

Sorry I am replying to a really old email, but exactly
what information do you believe would be more useful to
extract from vmscan.c with tracepoints?

What are the kinds of problems that customer systems
(which cannot be rebooted into experimental kernels)
run into, that can be tracked down with tracepoints?

I can think of a few:
- excessive CPU use in page reclaim code
- excessive reclaim latency in page reclaim code
- unbalanced memory allocation between zones/nodes
- strange balance problems between reclaiming of page
   cache and swapping out process pages

I suspect we would need fairly fine grained tracepoints
to track down these kinds of problems, with filtering
and/or interpretation in userspace, but I am always
interested in easier ways of tracking down these kinds
of problems :)

What kinds of tracepoints do you believe we would need?

Or, using Larry's patch as a starting point, what do you
believe should be changed?

-- 
All rights reversed.

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

  parent reply	other threads:[~2009-06-15 18:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21 22:45 [Patch] mm tracepoints update Larry Woodman
2009-04-22  1:00 ` KOSAKI Motohiro
2009-04-22  9:57   ` Ingo Molnar
2009-04-22 12:07     ` Larry Woodman
2009-04-22 19:22       ` [Patch] mm tracepoints update - use case Larry Woodman
2009-04-23  0:48         ` KOSAKI Motohiro
2009-04-23  4:50           ` Andrew Morton
2009-04-23  8:42             ` Ingo Molnar
2009-04-23 11:47               ` Larry Woodman
2009-04-24 20:48                 ` Larry Woodman
2009-06-15 18:26           ` Rik van Riel [this message]
2009-06-17 14:07             ` Larry Woodman
2009-06-18  7:57             ` KOSAKI Motohiro
2009-06-18 19:22               ` Larry Woodman
2009-06-18 19:40                 ` Rik van Riel
2009-06-22  3:37                   ` KOSAKI Motohiro
2009-06-22 15:04                     ` Larry Woodman
2009-06-23  5:52                       ` KOSAKI Motohiro
2009-06-22  3:37                 ` KOSAKI Motohiro
2009-06-22 15:28                   ` Larry Woodman

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=4A36925D.4090000@redhat.com \
    --to=riel@redhat.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=fweisbec@gmail.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=lwoodman@redhat.com \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --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 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).