From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with SMTP id p2SNvKLC192831 for ; Mon, 28 Mar 2011 18:57:21 -0500 Received: from mga03.intel.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B778A1DFA70B for ; Mon, 28 Mar 2011 17:00:28 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by cuda.sgi.com with ESMTP id 2oQ9sLTPwPhudkgS for ; Mon, 28 Mar 2011 17:00:28 -0700 (PDT) From: Andi Kleen Subject: Re: Very aggressive memory reclaim References: <20110328215344.GC3008@dastard> Date: Mon, 28 Mar 2011 16:58:50 -0700 In-Reply-To: <20110328215344.GC3008@dastard> (Dave Chinner's message of "Tue, 29 Mar 2011 08:53:44 +1100") Message-ID: MIME-Version: 1.0 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: Dave Chinner Cc: linux-mm@kvack.org, John Lepikhin , linux-kernel@vger.kernel.org, xfs@oss.sgi.com 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. There are a few other cases (like memory failure handling), but they're more obscure. -Andi -- ak@linux.intel.com -- Speaking for myself only _______________________________________________ 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 S932408Ab1C2AAf (ORCPT ); Mon, 28 Mar 2011 20:00:35 -0400 Received: from mga14.intel.com ([143.182.124.37]:27641 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932398Ab1C2AAb (ORCPT ); Mon, 28 Mar 2011 20:00:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.63,258,1299484800"; d="scan'208";a="410051214" From: Andi Kleen To: Dave Chinner Cc: John Lepikhin , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org Subject: Re: Very aggressive memory reclaim References: <20110328215344.GC3008@dastard> Date: Mon, 28 Mar 2011 16:58:50 -0700 In-Reply-To: <20110328215344.GC3008@dastard> (Dave Chinner's message of "Tue, 29 Mar 2011 08:53:44 +1100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. There are a few other cases (like memory failure handling), but they're more obscure. -Andi -- ak@linux.intel.com -- Speaking for myself only From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id B66368D0040 for ; Mon, 28 Mar 2011 20:00:28 -0400 (EDT) From: Andi Kleen Subject: Re: Very aggressive memory reclaim References: <20110328215344.GC3008@dastard> Date: Mon, 28 Mar 2011 16:58:50 -0700 In-Reply-To: <20110328215344.GC3008@dastard> (Dave Chinner's message of "Tue, 29 Mar 2011 08:53:44 +1100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org List-ID: To: Dave Chinner Cc: John Lepikhin , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org 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. There are a few other cases (like memory failure handling), but they're more obscure. -Andi -- ak@linux.intel.com -- Speaking for myself only -- 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