Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765484AbZFOS1k (ORCPT ); Mon, 15 Jun 2009 14:27:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754267AbZFOS1c (ORCPT ); Mon, 15 Jun 2009 14:27:32 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53613 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754462AbZFOS1b (ORCPT ); Mon, 15 Jun 2009 14:27:31 -0400 Message-ID: <4A36925D.4090000@redhat.com> Date: Mon, 15 Jun 2009 14:26:37 -0400 From: Rik van Riel Organization: Red Hat, Inc User-Agent: Thunderbird 2.0.0.17 (X11/20080915) MIME-Version: 1.0 To: KOSAKI Motohiro CC: Larry Woodman , Ingo Molnar , =?UTF-8?B?RnLpppjpp7tpYyBXZWlzYmVja2Vy?= , Li Zefan , Pekka Enberg , eduard.munteanu@linux360.ro, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rostedt@goodmis.org Subject: Re: [Patch] mm tracepoints update - use case. References: <1240402037.4682.3.camel@dhcp47-138.lab.bos.redhat.com> <1240428151.11613.46.camel@dhcp-100-19-198.bos.redhat.com> <20090423092933.F6E9.A69D9226@jp.fujitsu.com> In-Reply-To: <20090423092933.F6E9.A69D9226@jp.fujitsu.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1928 Lines: 50 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/