Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754178Ab2KIP0T (ORCPT ); Fri, 9 Nov 2012 10:26:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56166 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753527Ab2KIP0Q (ORCPT ); Fri, 9 Nov 2012 10:26:16 -0500 Date: Fri, 9 Nov 2012 12:58:29 -0200 From: Rafael Aquini To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Rusty Russell , "Michael S. Tsirkin" , Rik van Riel , Andi Kleen , Andrew Morton , Konrad Rzeszutek Wilk , Minchan Kim , Peter Zijlstra , "Paul E. McKenney" Subject: Re: [PATCH v11 7/7] mm: add vm event counters for balloon pages compaction Message-ID: <20121109145829.GC4308@optiplex.redhat.com> References: <8dde7996f3e36a5efbe569afe1aadfc84355e79e.1352256088.git.aquini@redhat.com> <20121109122033.GR3886@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121109122033.GR3886@csn.ul.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1654 Lines: 38 On Fri, Nov 09, 2012 at 12:20:33PM +0000, Mel Gorman wrote: > On Wed, Nov 07, 2012 at 01:05:54AM -0200, Rafael Aquini wrote: > > This patch introduces a new set of vm event counters to keep track of > > ballooned pages compaction activity. > > > > Signed-off-by: Rafael Aquini > > Other than confirming the thing actually works can any meaningful > conclusions be drawn from this counters? > > I know I have been inconsistent on this myself in the past but recently > I've been taking the attitude that the counters can be used to fit into > some other metric. I'm looking to change the compaction counters to be > able to build a basic cost model for example. The same idea could be > used for balloons of course but it's a less critical path than > compaction for THP for example. > > Assuming it builds and all the defines are correct when the feature is > not configured (I didn't check) then there is nothing wrong with the > patch. However, if it was dropped would it make life very hard or would > you notice? > Originally, I proposed this patch as droppable (and it's still droppable) because its major purpose was solely to show the thing working consistently OTOH, it might make the life easier to spot breakages if it remains with the merged bits, and per a reviewer request I removed its 'DROP BEFORE MERGE' disclaimer. https://lkml.org/lkml/2012/8/8/616 -- Rafael -- 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/