From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752184AbbCQHHi (ORCPT ); Tue, 17 Mar 2015 03:07:38 -0400 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:5076 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbbCQHHf (ORCPT ); Tue, 17 Mar 2015 03:07:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BCFwBS0gdV/wYQLHlbgwaBLII+sBoBAQECAQaYdgICAQECgTVNAQEBAQEBfYQQAQU6HCMQCAMOCgklDwUlAyETiC7JBgEBAQEGAgEfGIVyhQ2EcQeDF4EWBZomgRyDLI9TI4QCKjGCQwEBAQ Date: Tue, 17 Mar 2015 18:06:55 +1100 From: Dave Chinner To: Mel Gorman Cc: Linus Torvalds , Ingo Molnar , Andrew Morton , Aneesh Kumar , Linux Kernel Mailing List , Linux-MM , xfs@oss.sgi.com, ppc-dev Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur Message-ID: <20150317070655.GB10105@dastard> References: <20150308100223.GC15487@gmail.com> <20150309112936.GD26657@destitution> <20150309191943.GF26657@destitution> <20150312131045.GE3406@suse.de> <20150312184925.GH3406@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150312184925.GH3406@suse.de> 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 On Thu, Mar 12, 2015 at 06:49:26PM +0000, Mel Gorman wrote: > On Thu, Mar 12, 2015 at 09:20:36AM -0700, Linus Torvalds wrote: > > On Thu, Mar 12, 2015 at 6:10 AM, Mel Gorman wrote: > > > > > > I believe you're correct and it matches what was observed. I'm still > > > travelling and wireless is dirt but managed to queue a test using pmd_dirty > > > > Ok, thanks. > > > > I'm not entirely happy with that change, and I suspect the whole > > heuristic should be looked at much more (maybe it should also look at > > whether it's executable, for example), but it's a step in the right > > direction. > > > > I can follow up when I'm back in work properly. As you have already pulled > this in directly, can you also consider pulling in "mm: thp: return the > correct value for change_huge_pmd" please? The other two patches were very > minor can be resent through the normal paths later. TO close the loop here, now I'm back home and can run tests: config 3.19 4.0-rc1 4.0-rc4 defaults 8m08s 9m34s 9m14s -o ag_stride=-1 4m04s 4m38s 4m11s -o bhash=101073 6m04s 17m43s 7m35s -o ag_stride=-1,bhash=101073 4m54s 9m58s 7m50s It's better but there are still significant regressions, especially for the large memory footprint cases. I haven't had a chance to look at any stats or profiles yet, so I don't know yet whether this is still page fault related or some other problem.... Cheers, Dave -- Dave Chinner david@fromorbit.com