From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754043AbbCSXFt (ORCPT ); Thu, 19 Mar 2015 19:05:49 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:35420 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752980AbbCSXFr (ORCPT ); Thu, 19 Mar 2015 19:05:47 -0400 MIME-Version: 1.0 In-Reply-To: <20150319224143.GI10105@dastard> References: <20150312184925.GH3406@suse.de> <20150317070655.GB10105@dastard> <20150317205104.GA28621@dastard> <20150317220840.GC28621@dastard> <20150319224143.GI10105@dastard> Date: Thu, 19 Mar 2015 16:05:46 -0700 X-Google-Sender-Auth: SkjKtiXyuXov1HVgpccbO8xVO8U Message-ID: Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur From: Linus Torvalds To: Dave Chinner Cc: Mel Gorman , Ingo Molnar , Andrew Morton , Aneesh Kumar , Linux Kernel Mailing List , Linux-MM , xfs@oss.sgi.com, ppc-dev Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 19, 2015 at 3:41 PM, Dave Chinner wrote: > > My recollection wasn't faulty - I pulled it from an earlier email. > That said, the original measurement might have been faulty. I ran > the numbers again on the 3.19 kernel I saved away from the original > testing. That came up at 235k, which is pretty much the same as > yesterday's test. The runtime,however, is unchanged from my original > measurements of 4m54s (pte_hack came in at 5m20s). Ok. Good. So the "more than an order of magnitude difference" was really about measurement differences, not quite as real. Looks like more a "factor of two" than a factor of 20. Did you do the profiles the same way? Because that would explain the differences in the TLB flush percentages too (the "1.4% from tlb_invalidate_range()" vs "pretty much everything from migration"). The runtime variation does show that there's some *big* subtle difference for the numa balancing in the exact TNF_NO_GROUP details. It must be *very* unstable for it to make that big of a difference. But I feel at least a *bit* better about "unstable algorithm changes a small varioation into a factor-of-two" vs that crazy factor-of-20. Can you try Mel's change to make it use if (!(vma->vm_flags & VM_WRITE)) instead of the pte details? Again, on otherwise plain 3.19, just so that we have a baseline. I'd be *so* much happer with checking the vma details over per-pte details, especially ones that change over the lifetime of the pte entry, and the NUMA code explicitly mucks with. Linus