From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with SMTP id p2T8ua5o218685 for ; Tue, 29 Mar 2011 03:56:37 -0500 Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 41206387C24 for ; Tue, 29 Mar 2011 01:59:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XZNK1DSGAq9u8o8H for ; Tue, 29 Mar 2011 01:59:46 -0700 (PDT) Message-ID: <4D919F75.5070601@redhat.com> Date: Tue, 29 Mar 2011 10:59:33 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: Very aggressive memory reclaim References: <20110328215344.GC3008@dastard> In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: John Lepikhin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com On 03/29/2011 09:26 AM, John Lepikhin wrote: > 2011/3/29 Dave Chinner: > > > First it would be useful to determine why the VM is reclaiming so > > much memory. If it is somewhat predictable when the excessive > > reclaim is going to happen, it might be worth capturing an event > > trace from the VM so we can see more precisely what it is doiing > > during this event. In that case, recording the kmem/* and vmscan/* > > events is probably sufficient to tell us what memory allocations > > triggered reclaim and how much reclaim was done on each event. > > Do you mean I must add some debug to mm functions? I don't know any > other way to catch such events. Download and build trace-cmd (git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git), and do $ trace-cmd record -e kmem -e vmscan -b 30000 Hit ctrl-C when done and post the output file generated in cwd. -- error compiling committee.c: too many arguments to function _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752212Ab1C2I7u (ORCPT ); Tue, 29 Mar 2011 04:59:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53833 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237Ab1C2I7r (ORCPT ); Tue, 29 Mar 2011 04:59:47 -0400 Message-ID: <4D919F75.5070601@redhat.com> Date: Tue, 29 Mar 2011 10:59:33 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: John Lepikhin CC: Dave Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org Subject: Re: Very aggressive memory reclaim References: <20110328215344.GC3008@dastard> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/29/2011 09:26 AM, John Lepikhin wrote: > 2011/3/29 Dave Chinner: > > > First it would be useful to determine why the VM is reclaiming so > > much memory. If it is somewhat predictable when the excessive > > reclaim is going to happen, it might be worth capturing an event > > trace from the VM so we can see more precisely what it is doiing > > during this event. In that case, recording the kmem/* and vmscan/* > > events is probably sufficient to tell us what memory allocations > > triggered reclaim and how much reclaim was done on each event. > > Do you mean I must add some debug to mm functions? I don't know any > other way to catch such events. Download and build trace-cmd (git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git), and do $ trace-cmd record -e kmem -e vmscan -b 30000 Hit ctrl-C when done and post the output file generated in cwd. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with SMTP id 20BF48D0040 for ; Tue, 29 Mar 2011 04:59:47 -0400 (EDT) Message-ID: <4D919F75.5070601@redhat.com> Date: Tue, 29 Mar 2011 10:59:33 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: Very aggressive memory reclaim References: <20110328215344.GC3008@dastard> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: John Lepikhin Cc: Dave Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org On 03/29/2011 09:26 AM, John Lepikhin wrote: > 2011/3/29 Dave Chinner: > > > First it would be useful to determine why the VM is reclaiming so > > much memory. If it is somewhat predictable when the excessive > > reclaim is going to happen, it might be worth capturing an event > > trace from the VM so we can see more precisely what it is doiing > > during this event. In that case, recording the kmem/* and vmscan/* > > events is probably sufficient to tell us what memory allocations > > triggered reclaim and how much reclaim was done on each event. > > Do you mean I must add some debug to mm functions? I don't know any > other way to catch such events. Download and build trace-cmd (git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git), and do $ trace-cmd record -e kmem -e vmscan -b 30000 Hit ctrl-C when done and post the output file generated in cwd. -- error compiling committee.c: too many arguments to function -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org