Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753846AbZCFMfS (ORCPT ); Fri, 6 Mar 2009 07:35:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750744AbZCFMfE (ORCPT ); Fri, 6 Mar 2009 07:35:04 -0500 Received: from mx2.redhat.com ([66.187.237.31]:37132 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750721AbZCFMfD (ORCPT ); Fri, 6 Mar 2009 07:35:03 -0500 Subject: Re: [Patch] mm tracepoints From: Larry Woodman To: Ingo Molnar Cc: Steven Rostedt , KOSAKI Motohiro , linux-kernel@vger.kernel.org, peterz@infradead.org, fweisbec@gmail.com, Peter Zijlstra In-Reply-To: <20090306110423.GD21168@elte.hu> References: <1233306324.11332.11.camel@nigel-laptop> <1236291400.1476.50.camel@dhcp-100-19-198.bos.redhat.com> <20090306105627.3EF0.A69D9226@jp.fujitsu.com> <20090306110423.GD21168@elte.hu> Content-Type: text/plain Date: Fri, 06 Mar 2009 07:33:17 -0500 Message-Id: <1236342797.3154.1.camel@dhcp47-138.lab.bos.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2579 Lines: 70 On Fri, 2009-03-06 at 12:04 +0100, Ingo Molnar wrote: > * Steven Rostedt wrote: > > > > > On Fri, 6 Mar 2009, KOSAKI Motohiro wrote: > > > > > > I've implemented several mm tracepoints to track page allocation and > > > > freeing, various types of pagefaults and unmaps, and critical page > > > > reclamation routines. This is useful for debugging memory allocation > > > > issues and system performance problems under heavy memory loads: > > > > > > > > # tracer: mm > > > > # > > > > # TASK-PID CPU# TIMESTAMP FUNCTION > > > > # | | | | | > > > > pdflush-624 [004] 184.293169: wb_kupdate: > > > > (mm_pdflush_kupdate) count=3e48 > > > > pdflush-624 [004] 184.293439: get_page_from_freelist: > > > > (mm_page_allocation) pfn=447c27 zone_free=1940910 > > > > events/6-33 [006] 184.962879: free_hot_cold_page: > > > > (mm_page_free) pfn=44bba9 > > > > irqbalance-8313 [001] 188.042951: unmap_vmas: > > > > (mm_anon_userfree) mm=ffff88044a7300c0 address=7f9a2eb70000 pfn=24c29a > > > > cat-9122 [005] 191.141173: filemap_fault: > > > > (mm_filemap_fault) primary fault: mm=ffff88024c9d8f40 address=3cea2dd000 > > > > pfn=44d68e > > > > cat-9122 [001] 191.143036: handle_mm_fault: > > > > (mm_anon_fault) mm=ffff88024c8beb40 address=7fffbde99f94 pfn=24ce22 > > > > ... > > > > > > Hi Larry, > > > > > > I've started to evaluate your patch. > > > > > > firstly, this patch can't apply tip/master. > > yeah, would be nice to have a patch against: > > http://people.redhat.com/mingo/tip.git/README Yeah I'll fix that, it is a moving target. > > > > secondly, I don't think the address of mm_struct and pfn > > > help to analysis. administrator don't know the page is which > > > file's cache. > > > > The mm_struct may not be helpful since there should be a 1 to > > 1 mapping between user tasks and the mm struct. Hmm, maybe > > not, due to threads? > > Correct - so the mm ID looks useful. > > > But the pfn is helpful since it is a unique identifier for > > what physical page was mapped. > > Yeah. Nevertheless some sort of filename:offset indicator would > be nice too. (as an add-on) You mean in the filemap pagefault case??? Thanks, Larry > > Ingo -- 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/