From mboxrd@z Thu Jan 1 00:00:00 1970 From: William Kucharski Subject: Re: [PATCH -next 0/3] Add support for fast mremap Date: Sun, 4 Nov 2018 00:56:48 -0600 Message-ID: References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Content-Type: text/plain; charset="us-ascii" Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org, Rich Felker , linux-sh@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Will Deacon , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Michal Hocko , linux-mm@kvack.org, lokeshgidra@google.com, sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-riscv@lists.infradead.org, elfring@users.sourceforge.net, Jonas Bonn , kvmarm@lists.cs.columbia.edu, dancol@google.com, linux-ia64@vge.kvack.org, Yoshinori Sato , linux-xtensa@linux-xtensa.org, Richard Weinberger , Helge Deller , r.kernel.org@lithops.sigma-star.at, hughd@google.com, "James E.J. Bottomley" Return-path: In-Reply-To: <20181103183208.GA56850@google.com> List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski From mboxrd@z Thu Jan 1 00:00:00 1970 From: William Kucharski Subject: Re: [PATCH -next 0/3] Add support for fast mremap Date: Sun, 4 Nov 2018 00:56:48 -0600 Message-ID: References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181103183208.GA56850@google.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org To: Joel Fernandes Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org, Rich Felker , linux-sh@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Will Deacon , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Michal Hocko , linux-mm@kvack.org, lokeshgidra@google.com, sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-riscv@lists.infradead.org, elfring@users.sourceforge.net, Jonas Bonn , kvmarm@lists.cs.columbia.edu, dancol@google.com, linux-ia64@vge.kvack.org, Yoshinori Sato , linux-xtensa@linux-xtensa.org, Richard Weinberger , Helge Deller , r.kernel.org@lithops.sigma-star.at, hughd@google.com, "James E.J. Bottomley" List-Id: linux-m68k@vger.kernel.org > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2018 07:59:23 +0100 (CET) Received: from userp2130.oracle.com ([156.151.31.86]:34748 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992289AbeKDG7DrQqiU convert rfc822-to-8bit (ORCPT ); Sun, 4 Nov 2018 07:59:03 +0100 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA46u6n9035325; Sun, 4 Nov 2018 06:57:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Dv2JIDyr6hj+SI1f67+zM2v2M4uA+R2C7fKFV5CQ+kE=; b=Js7Nh27vbqOyY2gZ0UpqFfC92w4EMKr/VwCtgb/4hz0cpD+muu4dt9mHR/RIg7LXLRKM KSdQlyKUBJ0Wepu8UCnGYCRdHpxOUY3LSEVv1pS+k+mLUIjCdfn6slguWQuKOfCVqlp8 L9lqOMCdjJaGmZq1nHUWfgmmHv1CnRaeRXXjaAPM2Xi2w1DSFM+8xUpoxcjRF6GwcHR2 Q8VGkhI55EFSCNDiU2BqFcJrF9NDtefdCtLLfW7nm+lXI8yZIprvLVxRVTeAfWiOYVVD vSRxnGitTcbrLliDWcoiH4FzDASOny4srW6qN47aUOBPO6AznnIha2Je6/kcXA9kalmP rQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2nh33tjd1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 04 Nov 2018 06:57:32 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA46vJtx021700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 4 Nov 2018 06:57:21 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA46urU6025556; Sun, 4 Nov 2018 06:56:56 GMT Received: from [192.168.0.110] (/73.243.10.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Nov 2018 23:56:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH -next 0/3] Add support for fast mremap From: William Kucharski In-Reply-To: <20181103183208.GA56850@google.com> Date: Sun, 4 Nov 2018 00:56:48 -0600 Cc: Anton Ivanov , Richard Weinberger , LKML , kernel-team@android.com, Andrew Morton , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Chris Zankel , dancol@google.com, Dave Hansen , "David S. Miller" , elfring@users.sourceforge.net, Fenghua Yu , Geert Uytterhoeven , Guan Xuetao , Helge Deller , hughd@google.com, Ingo Molnar , "James E.J. Bottomley" , Jeff Dike , Jonas Bonn , Julia Lawall , kasan-dev@googlegroups.com, "Kirill A. Shutemov" , kvmarm@lists.cs.columbia.edu, Ley Foon Tan , linux-alpha@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vge.kvack.org, r.kernel.org@lithops.sigma-star.at, linux-m68k@vger.kernel.org, linux-mips@linux-mips.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org, linux-xtensa@linux-xtensa.org, lokeshgidra@google.com, Max Filippov , Michal Hocko , minchan@kernel.org, nios2-dev@lists.rocketboards.org, pantin@google.com, Peter Zijlstra , Rich Felker , Sam Creasey , sparclinux@vger.kernel.org, Stafford Horne , Stefan Kristiansson , Thomas Gleixner , Tony Luck , Will Deacon , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Yoshinori Sato Content-Transfer-Encoding: 8BIT Message-Id: References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> To: Joel Fernandes X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9066 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811040066 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 67068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: william.kucharski@oracle.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski >From sashal@kernel.org Sun Nov 4 14:52:25 2018 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2018 14:52:29 +0100 (CET) Received: from mail.kernel.org ([198.145.29.99]:33462 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992810AbeKDNwZBoLdg (ORCPT ); Sun, 4 Nov 2018 14:52:25 +0100 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A42F20866; Sun, 4 Nov 2018 13:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1541339543; bh=/BNA8wX7ezLJDRNO318yDehwFgvKzP2/YSC1SLXa0ug=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GMM/Ode4B8ym5bxpHINVTpOaARBN1H3PeHhA9zO1FIYmcSrQLdbpWn31Ro2ZEzqlD PCozg49NJy0NNUoFAQF7fts18r8FCWwB+JFCe6wD64wBcbdc+AuLJ6V/ybj1Hd4/FU cTOYZkkip07EftpCziwfl5Hjp+rtB7dJxlFQf8Eo= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Dengcheng Zhu , Paul Burton , pburton@wavecomp.com, ralf@linux-mips.org, linux-mips@linux-mips.org, rachel.mozes@intel.com, Sasha Levin Subject: [PATCH AUTOSEL 4.19 38/57] MIPS: kexec: Mark CPU offline before disabling local IRQ Date: Sun, 4 Nov 2018 08:51:25 -0500 Message-Id: <20181104135144.88324-38-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181104135144.88324-1-sashal@kernel.org> References: <20181104135144.88324-1-sashal@kernel.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 67069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sashal@kernel.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips From: Dengcheng Zhu [ Upstream commit dc57aaf95a516f70e2d527d8287a0332c481a226 ] After changing CPU online status, it will not be sent any IPIs such as in __flush_cache_all() on software coherency systems. Do this before disabling local IRQ. Signed-off-by: Dengcheng Zhu Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20571/ Cc: pburton@wavecomp.com Cc: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Cc: rachel.mozes@intel.com Signed-off-by: Sasha Levin --- arch/mips/kernel/crash.c | 3 +++ arch/mips/kernel/machine_kexec.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c index d455363d51c3..4c07a43a3242 100644 --- a/arch/mips/kernel/crash.c +++ b/arch/mips/kernel/crash.c @@ -36,6 +36,9 @@ static void crash_shutdown_secondary(void *passed_regs) if (!cpu_online(cpu)) return; + /* We won't be sent IPIs any more. */ + set_cpu_online(cpu, false); + local_irq_disable(); if (!cpumask_test_cpu(cpu, &cpus_in_crash)) crash_save_cpu(regs, cpu); diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c index 8b574bcd39ba..4b3726e4fe3a 100644 --- a/arch/mips/kernel/machine_kexec.c +++ b/arch/mips/kernel/machine_kexec.c @@ -118,6 +118,9 @@ machine_kexec(struct kimage *image) *ptr = (unsigned long) phys_to_virt(*ptr); } + /* Mark offline BEFORE disabling local irq. */ + set_cpu_online(smp_processor_id(), false); + /* * we do not want to be bothered. */ -- 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from userp2130.oracle.com ([156.151.31.86]:34748 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992289AbeKDG7DrQqiU convert rfc822-to-8bit (ORCPT ); Sun, 4 Nov 2018 07:59:03 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH -next 0/3] Add support for fast mremap From: William Kucharski In-Reply-To: <20181103183208.GA56850@google.com> Date: Sun, 4 Nov 2018 00:56:48 -0600 Content-Transfer-Encoding: 8BIT Message-ID: References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Joel Fernandes Cc: Anton Ivanov , Richard Weinberger , LKML , kernel-team@android.com, Andrew Morton , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Chris Zankel , dancol@google.com, Dave Hansen , "David S. Miller" , elfring@users.sourceforge.net, Fenghua Yu , Geert Uytterhoeven , Guan Xuetao , Helge Deller , hughd@google.com, Ingo Molnar , "James E.J. Bottomley" , Jeff Dike , Jonas Bonn , Julia Lawall , kasan-dev@googlegroups.com, "Kirill A. Shutemov" , kvmarm@lists.cs.columbia.edu, Ley Foon Tan , linux-alpha@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vge.kvack.org, r.kernel.org@lithops.sigma-star.at, linux-m68k@vger.kernel.org, linux-mips@linux-mips.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org, linux-xtensa@linux-xtensa.org, lokeshgidra@google.com, Max Filippov , Michal Hocko , minchan@kernel.org, nios2-dev@lists.rocketboards.org, pantin@google.com, Peter Zijlstra , Rich Felker , Sam Creasey , sparclinux@vger.kernel.org, Stafford Horne , Stefan Kristiansson , Thomas Gleixner , Tony Luck , Will Deacon , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Yoshinori Sato Message-ID: <20181104065648.2z5Sj33GLiWYTKQnbGRWYWW3DPcx3fxNbypsjRLjUgQ@z> > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski From mboxrd@z Thu Jan 1 00:00:00 1970 From: william.kucharski@oracle.com (William Kucharski) Date: Sun, 4 Nov 2018 00:56:48 -0600 Subject: [PATCH -next 0/3] Add support for fast mremap In-Reply-To: <20181103183208.GA56850@google.com> References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> Message-ID: To: linux-riscv@lists.infradead.org List-Id: linux-riscv.lists.infradead.org > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 847D8C32789 for ; Sun, 4 Nov 2018 06:59:40 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 39C292082E for ; Sun, 4 Nov 2018 06:59:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pJMxSOB7"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="Js7Nh27v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39C292082E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:References:Message-Id:Date: In-Reply-To:From:Subject:Mime-Version:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=T7WctkQ6PM/1ruDclrwBdkV1i+/Rpr3vN38Zxb3/hEM=; b=pJMxSOB70k59Dt OnlBmHdFN2TkEYoB2tJSz+hxoE67xDmA3wMtP9O9jd4hgnWcT2my+J6kR7G13t6iIE2wdplDc+H9V jMc2zY4YFKnzGmt5ml1c2GU+FnWy9MIeY2ldlZkfWFMO+/gUlJobt0BR2W/3H30LAyYGl+J3DCe/D MpJzT1JWVMgL58CXmvzQxS1O1EOWCvuMf+6BmhB01Zu/T9R1yrI9//gbdJgH6Hy++62bFm8H93hgk 5usMaj3FIxuFQJ1G07yPfvORSepcR/Pppj2ZyB1A1sd33tvAV4wbGq3p3XuvDNYBCd657G3/Zpdsd WDzXpqcbKi0XOOgKo6mA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gJCNl-0004TQ-Fm; Sun, 04 Nov 2018 06:59:37 +0000 Received: from userp2130.oracle.com ([156.151.31.86]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gJCNi-0004SL-7w; Sun, 04 Nov 2018 06:59:35 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA46u6n9035325; Sun, 4 Nov 2018 06:57:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Dv2JIDyr6hj+SI1f67+zM2v2M4uA+R2C7fKFV5CQ+kE=; b=Js7Nh27vbqOyY2gZ0UpqFfC92w4EMKr/VwCtgb/4hz0cpD+muu4dt9mHR/RIg7LXLRKM KSdQlyKUBJ0Wepu8UCnGYCRdHpxOUY3LSEVv1pS+k+mLUIjCdfn6slguWQuKOfCVqlp8 L9lqOMCdjJaGmZq1nHUWfgmmHv1CnRaeRXXjaAPM2Xi2w1DSFM+8xUpoxcjRF6GwcHR2 Q8VGkhI55EFSCNDiU2BqFcJrF9NDtefdCtLLfW7nm+lXI8yZIprvLVxRVTeAfWiOYVVD vSRxnGitTcbrLliDWcoiH4FzDASOny4srW6qN47aUOBPO6AznnIha2Je6/kcXA9kalmP rQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2nh33tjd1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 04 Nov 2018 06:57:32 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA46vJtx021700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 4 Nov 2018 06:57:21 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA46urU6025556; Sun, 4 Nov 2018 06:56:56 GMT Received: from [192.168.0.110] (/73.243.10.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Nov 2018 23:56:53 -0700 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH -next 0/3] Add support for fast mremap From: William Kucharski In-Reply-To: <20181103183208.GA56850@google.com> Date: Sun, 4 Nov 2018 00:56:48 -0600 Message-Id: References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> To: Joel Fernandes X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9066 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811040066 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181103_235934_423620_F7296ACC X-CRM114-Status: GOOD ( 21.59 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org, Rich Felker , linux-sh@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Will Deacon , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Michal Hocko , linux-mm@kvack.org, lokeshgidra@google.com, sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-riscv@lists.infradead.org, elfring@users.sourceforge.net, Jonas Bonn , kvmarm@lists.cs.columbia.edu, dancol@google.com, linux-ia64@vge.kvack.org, Yoshinori Sato , linux-xtensa@linux-xtensa.org, Richard Weinberger , Helge Deller , r.kernel.org@lithops.sigma-star.at, hughd@google.com, "James E.J. Bottomley" , kasan-dev@googlegroups.com, Anton Ivanov , Ingo Molnar , Geert Uytterhoeven , Andrey Ryabinin , linux-snps-arc@lists.infradead.org, kernel-team@android.com, Sam Creasey , Fenghua Yu , linux-s390@vger.kernel.org, Jeff Dike , linux-um@lists.infradead.org, Stefan Kristiansson , Julia Lawall , Borislav Petkov , Andy Lutomirski , nios2-dev@lists.rocketboards.org, "Kirill A. Shutemov" , Stafford Horne , Guan Xuetao , Chris Zankel , Tony Luck , linux-parisc@vger.kernel.org, Max Filippov , pantin@google.com, LKML , minchan@kernel.org, Thomas Gleixner , linux-alpha@vger.kernel.org, Ley Foon Tan , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org Message-ID: <20181104065648.yEt62BV8DCvcDkVEi1gpAYgRzFIqTpPh-EVVG0C1aAE@z> > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AF8FC0044C for ; Mon, 5 Nov 2018 05:03:00 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 694762082A for ; Mon, 5 Nov 2018 05:02:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="Js7Nh27v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 694762082A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 42pLCj27X4zDrqW for ; Mon, 5 Nov 2018 16:02:57 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="Js7Nh27v"; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=oracle.com (client-ip=156.151.31.86; helo=userp2130.oracle.com; envelope-from=william.kucharski@oracle.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="Js7Nh27v"; dkim-atps=neutral Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42ntxk6MqRzDrPZ for ; Sun, 4 Nov 2018 22:34:18 +1100 (AEDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA46u6n9035325; Sun, 4 Nov 2018 06:57:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Dv2JIDyr6hj+SI1f67+zM2v2M4uA+R2C7fKFV5CQ+kE=; b=Js7Nh27vbqOyY2gZ0UpqFfC92w4EMKr/VwCtgb/4hz0cpD+muu4dt9mHR/RIg7LXLRKM KSdQlyKUBJ0Wepu8UCnGYCRdHpxOUY3LSEVv1pS+k+mLUIjCdfn6slguWQuKOfCVqlp8 L9lqOMCdjJaGmZq1nHUWfgmmHv1CnRaeRXXjaAPM2Xi2w1DSFM+8xUpoxcjRF6GwcHR2 Q8VGkhI55EFSCNDiU2BqFcJrF9NDtefdCtLLfW7nm+lXI8yZIprvLVxRVTeAfWiOYVVD vSRxnGitTcbrLliDWcoiH4FzDASOny4srW6qN47aUOBPO6AznnIha2Je6/kcXA9kalmP rQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2nh33tjd1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 04 Nov 2018 06:57:32 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA46vJtx021700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 4 Nov 2018 06:57:21 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA46urU6025556; Sun, 4 Nov 2018 06:56:56 GMT Received: from [192.168.0.110] (/73.243.10.6) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Nov 2018 23:56:53 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH -next 0/3] Add support for fast mremap From: William Kucharski In-Reply-To: <20181103183208.GA56850@google.com> Date: Sun, 4 Nov 2018 00:56:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> To: Joel Fernandes X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9066 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811040066 X-Mailman-Approved-At: Mon, 05 Nov 2018 16:00:35 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org, Rich Felker , linux-sh@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Will Deacon , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Michal Hocko , linux-mm@kvack.org, lokeshgidra@google.com, sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-riscv@lists.infradead.org, elfring@users.sourceforge.net, Jonas Bonn , kvmarm@lists.cs.columbia.edu, dancol@google.com, linux-ia64@vge.kvack.org, Yoshinori Sato , linux-xtensa@linux-xtensa.org, Richard Weinberger , Helge Deller , r.kernel.org@lithops.sigma-star.at, hughd@google.com, "James E.J. Bottomley" , kasan-dev@googlegroups.com, Anton Ivanov , Ingo Molnar , Geert Uytterhoeven , Andrey Ryabinin , linux-snps-arc@lists.infradead.org, kernel-team@android.com, Sam Creasey , Fenghua Yu , linux-s390@vger.kernel.org, Jeff Dike , linux-um@lists.infradead.org, Stefan Kristiansson , Julia Lawall , Borislav Petkov , Andy Lutomirski , nios2-dev@lists.rocketboards.org, "Kirill A. Shutemov" , Stafford Horne , Guan Xuetao , Chris Zankel , Tony Luck , linux-parisc@vger.kernel.org, Max Filippov , pantin@google.com, LKML , minchan@kernel.org, Thomas Gleixner , linux-alpha@vger.kernel.org, Ley Foon Tan , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" > On Nov 3, 2018, at 12:32 PM, Joel Fernandes = wrote: >=20 > Looks like more architectures don't define set_pmd_at. I am thinking = the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. = Thoughts? >=20 > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct = vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent =3D=3D PMD_SIZE && = IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent =3D=3D PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the = move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct = vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } >=20 > if (pte_alloc(new_vma->vm_mm, new_pmd)) >=20 That seems reasonable as there are going to be a lot of architectures = that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to = be able to perform remaps at the PUD level, given many architectures already = support PUD-mapped pages? William Kucharski= From mboxrd@z Thu Jan 1 00:00:00 1970 From: william.kucharski@oracle.com (William Kucharski) Date: Sun, 4 Nov 2018 00:56:48 -0600 Subject: [PATCH -next 0/3] Add support for fast mremap In-Reply-To: <20181103183208.GA56850@google.com> References: <20181103040041.7085-1-joelaf@google.com> <6886607.O3ZT5bM3Cy@blindfold> <20181103183208.GA56850@google.com> List-ID: Message-ID: To: linux-snps-arc@lists.infradead.org > On Nov 3, 2018,@12:32 PM, Joel Fernandes wrote: > > Looks like more architectures don't define set_pmd_at. I am thinking the > easiest way forward is to just do the following, instead of defining > set_pmd_at for every architecture that doesn't care about it. Thoughts? > > diff --git a/mm/mremap.c b/mm/mremap.c > index 7cf6b0943090..31ad64dcdae6 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -281,7 +281,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > split_huge_pmd(vma, old_pmd, old_addr); > if (pmd_trans_unstable(old_pmd)) > continue; > - } else if (extent == PMD_SIZE && IS_ENABLED(CONFIG_HAVE_MOVE_PMD)) { > + } else if (extent == PMD_SIZE) { > +#ifdef CONFIG_HAVE_MOVE_PMD > /* > * If the extent is PMD-sized, try to speed the move by > * moving at the PMD level if possible. > @@ -296,6 +297,7 @@ unsigned long move_page_tables(struct vm_area_struct *vma, > drop_rmap_locks(vma); > if (moved) > continue; > +#endif > } > > if (pte_alloc(new_vma->vm_mm, new_pmd)) > That seems reasonable as there are going to be a lot of architectures that never have mappings at the PMD level. Have you thought about what might be needed to extend this paradigm to be able to perform remaps at the PUD level, given many architectures already support PUD-mapped pages? William Kucharski