Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759875AbbLCLfM (ORCPT ); Thu, 3 Dec 2015 06:35:12 -0500 Received: from mga09.intel.com ([134.134.136.24]:28840 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752085AbbLCLfL (ORCPT ); Thu, 3 Dec 2015 06:35:11 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,378,1444719600"; d="scan'208";a="611846040" Date: Thu, 3 Dec 2015 19:35:08 +0800 From: Aaron Lu To: Vlastimil Babka Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim , Rik van Riel , David Rientjes , Mel Gorman , Minchan Kim Subject: Re: [RFC 0/3] reduce latency of direct async compaction Message-ID: <20151203113508.GA23780@aaronlu.sh.intel.com> References: <1449130247-8040-1-git-send-email-vbabka@suse.cz> <20151203092525.GA20945@aaronlu.sh.intel.com> <56600DAA.4050208@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56600DAA.4050208@suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1472 Lines: 35 On Thu, Dec 03, 2015 at 10:38:50AM +0100, Vlastimil Babka wrote: > On 12/03/2015 10:25 AM, Aaron Lu wrote: > > On Thu, Dec 03, 2015 at 09:10:44AM +0100, Vlastimil Babka wrote: > >> Aaron, could you try this on your testcase? > > > > The test result is placed at: > > https://drive.google.com/file/d/0B49uX3igf4K4enBkdVFScXhFM0U > > > > For some reason, the patches made the performace worse. The base tree is > > today's Linus git 25364a9e54fb8296837061bf684b76d20eec01fb, and its > > performace is about 1000MB/s. After applying this patch series, the > > performace drops to 720MB/s. > > > > Please let me know if you need more information, thanks. > > Hm, compaction stats are at 0. The code in the patches isn't even running. > Can you provide the same data also for the base tree? My bad, I uploaded the wrong data :-/ I uploaded again: https://drive.google.com/file/d/0B49uX3igf4K4UFI4TEQ3THYta0E And I just run the base tree with trace-cmd and found that its performace drops significantly(from 1000MB/s to 6xxMB/s), is it that trace-cmd will impact performace a lot? Any suggestions on how to run the test regarding trace-cmd? i.e. should I aways run usemem under trace-cmd or only when necessary? Thanks, Aaron -- 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/