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 p2T1sLCU197697 for ; Mon, 28 Mar 2011 20:54:21 -0500 Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DCC8A384D9C for ; Mon, 28 Mar 2011 18:57:30 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id 7roT2tST1J1NUvzT for ; Mon, 28 Mar 2011 18:57:30 -0700 (PDT) Date: Tue, 29 Mar 2011 12:57:27 +1100 From: Dave Chinner Subject: Re: Very aggressive memory reclaim Message-ID: <20110329015727.GE3008@dastard> References: <20110328215344.GC3008@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Andi Kleen Cc: linux-mm@kvack.org, John Lepikhin , linux-kernel@vger.kernel.org, xfs@oss.sgi.com On Mon, Mar 28, 2011 at 04:58:50PM -0700, Andi Kleen wrote: > Dave Chinner writes: > > > > 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 > > Often it's to get pages of a higher order. Just tracing alloc_pages > should tell you that. Yes, the kmem/mm_page_alloc tracepoint gives us that. But in case that is not the cause, grabbing all the trace points I suggested is more likely to indicate where the problem is. I'd prefer to get more data than needed the first time around than have to do multiple round trips because a single trace point doesn't tell us the cause... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ 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 S1755141Ab1C2B5c (ORCPT ); Mon, 28 Mar 2011 21:57:32 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:47740 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754550Ab1C2B5b (ORCPT ); Mon, 28 Mar 2011 21:57:31 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMEAJY5kU15LK5JgWdsb2JhbAClSBUBARYmJcUjDYVdBA Date: Tue, 29 Mar 2011 12:57:27 +1100 From: Dave Chinner To: Andi Kleen Cc: John Lepikhin , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org Subject: Re: Very aggressive memory reclaim Message-ID: <20110329015727.GE3008@dastard> References: <20110328215344.GC3008@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 28, 2011 at 04:58:50PM -0700, Andi Kleen wrote: > Dave Chinner writes: > > > > 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 > > Often it's to get pages of a higher order. Just tracing alloc_pages > should tell you that. Yes, the kmem/mm_page_alloc tracepoint gives us that. But in case that is not the cause, grabbing all the trace points I suggested is more likely to indicate where the problem is. I'd prefer to get more data than needed the first time around than have to do multiple round trips because a single trace point doesn't tell us the cause... Cheers, Dave. -- Dave Chinner david@fromorbit.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id 6A38A8D0040 for ; Mon, 28 Mar 2011 21:57:32 -0400 (EDT) Date: Tue, 29 Mar 2011 12:57:27 +1100 From: Dave Chinner Subject: Re: Very aggressive memory reclaim Message-ID: <20110329015727.GE3008@dastard> References: <20110328215344.GC3008@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Andi Kleen Cc: John Lepikhin , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org On Mon, Mar 28, 2011 at 04:58:50PM -0700, Andi Kleen wrote: > Dave Chinner writes: > > > > 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 > > Often it's to get pages of a higher order. Just tracing alloc_pages > should tell you that. Yes, the kmem/mm_page_alloc tracepoint gives us that. But in case that is not the cause, grabbing all the trace points I suggested is more likely to indicate where the problem is. I'd prefer to get more data than needed the first time around than have to do multiple round trips because a single trace point doesn't tell us the cause... Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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