From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752057AbbCGTMx (ORCPT ); Sat, 7 Mar 2015 14:12:53 -0500 Received: from mail-ig0-f173.google.com ([209.85.213.173]:46403 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbbCGTMv (ORCPT ); Sat, 7 Mar 2015 14:12:51 -0500 MIME-Version: 1.0 In-Reply-To: <20150307163657.GA9702@gmail.com> References: <1425741651-29152-1-git-send-email-mgorman@suse.de> <1425741651-29152-5-git-send-email-mgorman@suse.de> <20150307163657.GA9702@gmail.com> Date: Sat, 7 Mar 2015 11:12:50 -0800 X-Google-Sender-Auth: -nRQM3gPzVM6gpK6c-ocxE_28cM Message-ID: Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur From: Linus Torvalds To: Ingo Molnar Cc: Mel Gorman , Dave Chinner , 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 Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote: > > And the patch Dave bisected to is a relatively simple patch. > Why not simply revert it to see whether that cures much of the > problem? So the problem with that is that "pmd_set_numa()" and friends simply no longer exist. So we can't just revert that one patch, it's the whole series, and the whole point of the series. What confuses me is that the only real change that I can see in that patch is the change to "change_huge_pmd()". Everything else is pretty much a 100% equivalent transformation, afaik. Of course, I may be wrong about that, and missing something silly. And the changes to "change_huge_pmd()" were basically re-done differently by subsequent patches anyway. The *only* change I see remaining is that change_huge_pmd() now does entry = pmdp_get_and_clear_notify(mm, addr, pmd); entry = pmd_modify(entry, newprot); set_pmd_at(mm, addr, pmd, entry); for all changes. It used to do that "pmdp_set_numa()" for the prot_numa case, which did just pmd_t pmd = *pmdp; pmd = pmd_mknuma(pmd); set_pmd_at(mm, addr, pmdp, pmd); instead. I don't like the old pmdp_set_numa() because it can drop dirty bits, so I think the old code was actively buggy. But I do *not* see why the new code would cause more migrations to happen. There's probably something really stupid I'm missing. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 19A907F51 for ; Sat, 7 Mar 2015 13:12:56 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id ED6E78F804B for ; Sat, 7 Mar 2015 11:12:52 -0800 (PST) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by cuda.sgi.com with ESMTP id w9yVAclhtrtc2ffM (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 07 Mar 2015 11:12:51 -0800 (PST) Received: by igjz20 with SMTP id z20so11832699igj.4 for ; Sat, 07 Mar 2015 11:12:50 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20150307163657.GA9702@gmail.com> References: <1425741651-29152-1-git-send-email-mgorman@suse.de> <1425741651-29152-5-git-send-email-mgorman@suse.de> <20150307163657.GA9702@gmail.com> Date: Sat, 7 Mar 2015 11:12:50 -0800 Message-ID: Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur From: Linus Torvalds 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 Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Ingo Molnar Cc: Linux Kernel Mailing List , xfs@oss.sgi.com, Linux-MM , Mel Gorman , Andrew Morton , ppc-dev , Aneesh Kumar On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote: > > And the patch Dave bisected to is a relatively simple patch. > Why not simply revert it to see whether that cures much of the > problem? So the problem with that is that "pmd_set_numa()" and friends simply no longer exist. So we can't just revert that one patch, it's the whole series, and the whole point of the series. What confuses me is that the only real change that I can see in that patch is the change to "change_huge_pmd()". Everything else is pretty much a 100% equivalent transformation, afaik. Of course, I may be wrong about that, and missing something silly. And the changes to "change_huge_pmd()" were basically re-done differently by subsequent patches anyway. The *only* change I see remaining is that change_huge_pmd() now does entry = pmdp_get_and_clear_notify(mm, addr, pmd); entry = pmd_modify(entry, newprot); set_pmd_at(mm, addr, pmd, entry); for all changes. It used to do that "pmdp_set_numa()" for the prot_numa case, which did just pmd_t pmd = *pmdp; pmd = pmd_mknuma(pmd); set_pmd_at(mm, addr, pmdp, pmd); instead. I don't like the old pmdp_set_numa() because it can drop dirty bits, so I think the old code was actively buggy. But I do *not* see why the new code would cause more migrations to happen. There's probably something really stupid I'm missing. Linus _______________________________________________ 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: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by kanga.kvack.org (Postfix) with ESMTP id 633336B0038 for ; Sat, 7 Mar 2015 14:12:51 -0500 (EST) Received: by iery20 with SMTP id y20so486746ier.0 for ; Sat, 07 Mar 2015 11:12:51 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com. [2607:f8b0:4001:c05::22b]) by mx.google.com with ESMTPS id c23si6738825iod.46.2015.03.07.11.12.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2015 11:12:50 -0800 (PST) Received: by igbhl2 with SMTP id hl2so11015165igb.0 for ; Sat, 07 Mar 2015 11:12:50 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20150307163657.GA9702@gmail.com> References: <1425741651-29152-1-git-send-email-mgorman@suse.de> <1425741651-29152-5-git-send-email-mgorman@suse.de> <20150307163657.GA9702@gmail.com> Date: Sat, 7 Mar 2015 11:12:50 -0800 Message-ID: Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Mel Gorman , Dave Chinner , Andrew Morton , Aneesh Kumar , Linux Kernel Mailing List , Linux-MM , xfs@oss.sgi.com, ppc-dev On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote: > > And the patch Dave bisected to is a relatively simple patch. > Why not simply revert it to see whether that cures much of the > problem? So the problem with that is that "pmd_set_numa()" and friends simply no longer exist. So we can't just revert that one patch, it's the whole series, and the whole point of the series. What confuses me is that the only real change that I can see in that patch is the change to "change_huge_pmd()". Everything else is pretty much a 100% equivalent transformation, afaik. Of course, I may be wrong about that, and missing something silly. And the changes to "change_huge_pmd()" were basically re-done differently by subsequent patches anyway. The *only* change I see remaining is that change_huge_pmd() now does entry = pmdp_get_and_clear_notify(mm, addr, pmd); entry = pmd_modify(entry, newprot); set_pmd_at(mm, addr, pmd, entry); for all changes. It used to do that "pmdp_set_numa()" for the prot_numa case, which did just pmd_t pmd = *pmdp; pmd = pmd_mknuma(pmd); set_pmd_at(mm, addr, pmdp, pmd); instead. I don't like the old pmdp_set_numa() because it can drop dirty bits, so I think the old code was actively buggy. But I do *not* see why the new code would cause more migrations to happen. There's probably something really stupid I'm missing. Linus -- 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/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id D0F4B1A0196 for ; Sun, 8 Mar 2015 06:12:53 +1100 (AEDT) Received: by igdh15 with SMTP id h15so11862448igd.3 for ; Sat, 07 Mar 2015 11:12:50 -0800 (PST) MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: <20150307163657.GA9702@gmail.com> References: <1425741651-29152-1-git-send-email-mgorman@suse.de> <1425741651-29152-5-git-send-email-mgorman@suse.de> <20150307163657.GA9702@gmail.com> Date: Sat, 7 Mar 2015 11:12:50 -0800 Message-ID: Subject: Re: [PATCH 4/4] mm: numa: Slow PTE scan rate if migration failures occur From: Linus Torvalds To: Ingo Molnar Content-Type: text/plain; charset=UTF-8 Cc: Dave Chinner , Linux Kernel Mailing List , xfs@oss.sgi.com, Linux-MM , Mel Gorman , Andrew Morton , ppc-dev , Aneesh Kumar List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote: > > And the patch Dave bisected to is a relatively simple patch. > Why not simply revert it to see whether that cures much of the > problem? So the problem with that is that "pmd_set_numa()" and friends simply no longer exist. So we can't just revert that one patch, it's the whole series, and the whole point of the series. What confuses me is that the only real change that I can see in that patch is the change to "change_huge_pmd()". Everything else is pretty much a 100% equivalent transformation, afaik. Of course, I may be wrong about that, and missing something silly. And the changes to "change_huge_pmd()" were basically re-done differently by subsequent patches anyway. The *only* change I see remaining is that change_huge_pmd() now does entry = pmdp_get_and_clear_notify(mm, addr, pmd); entry = pmd_modify(entry, newprot); set_pmd_at(mm, addr, pmd, entry); for all changes. It used to do that "pmdp_set_numa()" for the prot_numa case, which did just pmd_t pmd = *pmdp; pmd = pmd_mknuma(pmd); set_pmd_at(mm, addr, pmdp, pmd); instead. I don't like the old pmdp_set_numa() because it can drop dirty bits, so I think the old code was actively buggy. But I do *not* see why the new code would cause more migrations to happen. There's probably something really stupid I'm missing. Linus