From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by kanga.kvack.org (Postfix) with ESMTP id EF2636B033E for ; Sat, 27 Oct 2018 15:39:21 -0400 (EDT) Received: by mail-pf1-f198.google.com with SMTP id c28-v6so3453758pfe.4 for ; Sat, 27 Oct 2018 12:39:21 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 93-v6sor12582256plf.23.2018.10.27.12.39.20 for (Google Transport Security); Sat, 27 Oct 2018 12:39:20 -0700 (PDT) Date: Sat, 27 Oct 2018 12:39:17 -0700 From: Joel Fernandes Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2) Message-ID: <20181027193917.GA51131@joelaf.mtv.corp.google.com> References: <20181013013200.206928-1-joel@joelfernandes.org> <20181013013200.206928-3-joel@joelfernandes.org> <20181024101255.it4lptrjogalxbey@kshutemo-mobl1> <20181024115733.GN8537@350D> <20181025021350.GB13560@joelaf.mtv.corp.google.com> <20181027102102.GO8537@350D> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181027102102.GO8537@350D> Sender: owner-linux-mm@kvack.org List-ID: To: Balbir Singh Cc: "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, kernel-team@android.com, minchan@kernel.org, pantin@google.com, hughd@google.com, lokeshgidra@google.com, dancol@google.com, mhocko@kernel.org, akpm@linux-foundation.org, Andrey Ryabinin , Andy Lutomirski , anton.ivanov@kot-begemot.co.uk, Borislav Petkov , Catalin Marinas , Chris Zankel , Dave Hansen , "David S. Miller" , elfring@users.sourceforge.net, Fenghua Yu , Geert Uytterhoeven , Guan Xuetao , Helge Deller , Ingo Molnar , "James E.J. Bottomley" , Jeff Dike , Jonas Bonn , Julia Lawall , kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu, Ley Foon Tan , linux-alpha@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.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, Max Filippov , nios2-dev@lists.rocketboards.org, Peter Zijlstra , Richard Weinberger , 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 Hi Balbir, On Sat, Oct 27, 2018 at 09:21:02PM +1100, Balbir Singh wrote: > On Wed, Oct 24, 2018 at 07:13:50PM -0700, Joel Fernandes wrote: > > On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote: > > [...] > > > > > + pmd_t pmd; > > > > > + > > > > > + new_ptl = pmd_lockptr(mm, new_pmd); > > > > > > > > > Looks like this is largely inspired by move_huge_pmd(), I guess a lot of > > > the code applies, why not just reuse as much as possible? The same comments > > > w.r.t mmap_sem helping protect against lock order issues applies as well. > > > > I thought about this and when I looked into it, it seemed there are subtle > > differences that make such sharing not worth it (or not possible). > > > > Could you elaborate on them? The move_huge_page function is defined only for CONFIG_TRANSPARENT_HUGEPAGE so we cannot reuse it to begin with, since we have it disabled on our systems. I am not sure if it is a good idea to split that out and refactor it for reuse especially since our case is quite simple compared to huge pages. There are also a couple of subtle differences between the move_normal_pmd and the move_huge_pmd. Atleast 2 of them are: 1. We don't concern ourself with the PMD dirty bit, since the pages being moved are normal pages and at the soft-dirty bit accounting is at the PTE level, since we are not moving PTEs, we don't need to do that. 2. The locking is simpler as Kirill pointed, pmd_lock cannot fail however __pmd_trans_huge_lock can. I feel it is not super useful to refactor move_huge_pmd to support our case especially since move_normal_pmd is quite small, so IMHO the benefit of code reuse isn't there very much. Do let me know your thoughts and thanks for your interest in this. thanks, - Joel