From mboxrd@z Thu Jan 1 00:00:00 1970 From: kirill@shutemov.name (Kirill A. Shutemov) Date: Wed, 24 Oct 2018 15:57:24 +0300 Subject: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2) In-Reply-To: <20181024115733.GN8537@350D> References: <20181013013200.206928-1-joel@joelfernandes.org> <20181013013200.206928-3-joel@joelfernandes.org> <20181024101255.it4lptrjogalxbey@kshutemo-mobl1> <20181024115733.GN8537@350D> Message-ID: <20181024125724.yf6frdimjulf35do@kshutemo-mobl1> To: linux-riscv@lists.infradead.org List-Id: linux-riscv.lists.infradead.org On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote: > On Wed, Oct 24, 2018 at 01:12:56PM +0300, Kirill A. Shutemov wrote: > > On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote: > > > diff --git a/mm/mremap.c b/mm/mremap.c > > > index 9e68a02a52b1..2fd163cff406 100644 > > > --- a/mm/mremap.c > > > +++ b/mm/mremap.c > > > @@ -191,6 +191,54 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd, > > > drop_rmap_locks(vma); > > > } > > > > > > +static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr, > > > + unsigned long new_addr, unsigned long old_end, > > > + pmd_t *old_pmd, pmd_t *new_pmd, bool *need_flush) > > > +{ > > > + spinlock_t *old_ptl, *new_ptl; > > > + struct mm_struct *mm = vma->vm_mm; > > > + > > > + if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK) > > > + || old_end - old_addr < PMD_SIZE) > > > + return false; > > > + > > > + /* > > > + * The destination pmd shouldn't be established, free_pgtables() > > > + * should have release it. > > > + */ > > > + if (WARN_ON(!pmd_none(*new_pmd))) > > > + return false; > > > + > > > + /* > > > + * We don't have to worry about the ordering of src and dst > > > + * ptlocks because exclusive mmap_sem prevents deadlock. > > > + */ > > > + old_ptl = pmd_lock(vma->vm_mm, old_pmd); > > > + if (old_ptl) { > > > > How can it ever be false? > > > > > + 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. pmd_lock() cannot fail, but __pmd_trans_huge_lock() can. We should not copy the code blindly. -- Kirill A. Shutemov 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=-7.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,USER_AGENT_NEOMUTT 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 B78BCC67863 for ; Wed, 24 Oct 2018 12:57:48 +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 8823D2064A for ; Wed, 24 Oct 2018 12:57:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZCeOUh2V"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="QUWcy6Sl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8823D2064A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name 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:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YlOVR6ri3IOJ4nDDfzKqFXkXmDS028DxfU2S9ZLyp4U=; b=ZCeOUh2Vs/p3Qm S8ryJcghPT5f+tPoQxwNAiQ6z5Rjar5ZiuDLgo5By9lYWAf4CtRkKfRvpicUZV6KJeSeQqf8/6eIT jcLYYiZNQu96ax7QYRrgdHbiPsTGDWLQAm1fEwPh82eUBZ1+X22TZbAs1Mlzw3VBXqTW7ziAhGdLX 0tzUUtOHvP82YBcQgO3auwDV2FJjvAeQUgbcib9VGW8AiWrN5KaevAsAOYTvq0Nzpy1BiU2+urGCj KPntRde3fq4+GLaEjluSXu1vGxamS2upLO1XrigUPZNVvy2w4xhZjnTqKOAjoCAmW7fC83keOe62n tWC++xpBwmcTXA+peh0Q==; 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 1gFIjJ-0006KQ-HG; Wed, 24 Oct 2018 12:57:45 +0000 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gFIjF-0006J8-Oc for linux-riscv@lists.infradead.org; Wed, 24 Oct 2018 12:57:43 +0000 Received: by mail-pl1-x642.google.com with SMTP id f8-v6so2207723plb.2 for ; Wed, 24 Oct 2018 05:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=u4uba2fx6yj15XJfXzXAGhRcWjDfkikfuZTGMLXtNuw=; b=QUWcy6Sl2uKBSxMKyAQKgPHaaZkxUyGKW1j/tcrhbSXB3vW5a56lXmFSTP0gzGbZK3 vffkJDQW2WMbIFLuD1+6ufBku/+pf6UeruhfzRwNYwFgIuIJTiBEFtQd6OUHFAQ6eayl P+oyst7tx7B2tcyac+nAMIUnZnHfXCn48NySbAEzmKBcKrbkCpbDR97BYPvJugxN++Cj APyxLuPJd0VjY9bkSUeFLpZ1THRyudEGwY77knuPasZkTOLS31IxwdJtMwVSEmSEjNTT gafpbeBUtbqb+qibgmoy3fyXe8MHjyx6PnKU0Is89VSk3GMj5Rt4EKiaVNHGw+K4Tm+L MPaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=u4uba2fx6yj15XJfXzXAGhRcWjDfkikfuZTGMLXtNuw=; b=ElyF0Ye9SpeWugwzu4kT6Mb/NOLizC6PjCGCvQe9aaXHMBibCwQ6lLznEBMTbqCwC6 1SWuOpEpJKeXt8oa0RA68WdNmQpvYGxXGg9OXy0NJZCosD17CiXtshaGT8ZZAipviarN upKwq5vbQUsvHsEkqpGnQzBVOYIVZFPxsQib37pb7MoscYgnGwrfkZebUPI1qqGK1R0J DBuY8UCZt7Badao3DpyoQFGFG2aitwRavmyfTCemOLHLLeypFDQK32lfvjiNevQPxddj /ydjfuEZVagP1zURPUyug9uFVEnnEU2gAGnnFdv2t5jgOzhRuhjOf7BIRpDhINz2o38z z3PQ== X-Gm-Message-State: AGRZ1gLbOVCGytEpeVqRmp6guZyzgUVGQLaqwBCEhAE+kvfRN3+iFNip DUtPiC+cZuS6nzFsUASgkZ2OhA== X-Google-Smtp-Source: AJdET5f0Q09g2nkZdpmB3hAoSyWMxOfqRQx8u4VGhcieEr9jQ0pioGElufWMbGpMlhoL8pENMWgATQ== X-Received: by 2002:a17:902:bf02:: with SMTP id bi2-v6mr2470661plb.186.1540385850462; Wed, 24 Oct 2018 05:57:30 -0700 (PDT) Received: from kshutemo-mobl1.localdomain ([192.55.54.44]) by smtp.gmail.com with ESMTPSA id l83-v6sm10557314pfi.172.2018.10.24.05.57.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 05:57:29 -0700 (PDT) Received: by kshutemo-mobl1.localdomain (Postfix, from userid 1000) id 1845F300225; Wed, 24 Oct 2018 15:57:24 +0300 (+03) Date: Wed, 24 Oct 2018 15:57:24 +0300 From: "Kirill A. Shutemov" To: Balbir Singh Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2) Message-ID: <20181024125724.yf6frdimjulf35do@kshutemo-mobl1> References: <20181013013200.206928-1-joel@joelfernandes.org> <20181013013200.206928-3-joel@joelfernandes.org> <20181024101255.it4lptrjogalxbey@kshutemo-mobl1> <20181024115733.GN8537@350D> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20181024115733.GN8537@350D> User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181024_055741_832328_9E0530C1 X-CRM114-Status: GOOD ( 18.88 ) 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, Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Will Deacon , mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com, "Joel Fernandes \(Google\)" , linux-riscv@lists.infradead.org, elfring@users.sourceforge.net, Jonas Bonn , kvmarm@lists.cs.columbia.edu, dancol@google.com, Yoshinori Sato , sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-hexagon@vger.kernel.org, Helge Deller , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , hughd@google.com, "James E.J. Bottomley" , kasan-dev@googlegroups.com, anton.ivanov@kot-begemot.co.uk, 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 , linux-m68k@lists.linux-m68k.org, Borislav Petkov , Andy Lutomirski , nios2-dev@lists.rocketboards.org, Stafford Horne , Guan Xuetao , Chris Zankel , Tony Luck , Richard Weinberger , linux-parisc@vger.kernel.org, pantin@google.com, Max Filippov , linux-kernel@vger.kernel.org, minchan@kernel.org, Thomas Gleixner , linux-alpha@vger.kernel.org, Ley Foon Tan , akpm@linux-foundation.org, 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: <20181024125724._hZYb0wUf_cwlM3uuHiDJ1HA6tT25wMYbdXuDT8iHm4@z> On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote: > On Wed, Oct 24, 2018 at 01:12:56PM +0300, Kirill A. Shutemov wrote: > > On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote: > > > diff --git a/mm/mremap.c b/mm/mremap.c > > > index 9e68a02a52b1..2fd163cff406 100644 > > > --- a/mm/mremap.c > > > +++ b/mm/mremap.c > > > @@ -191,6 +191,54 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd, > > > drop_rmap_locks(vma); > > > } > > > > > > +static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr, > > > + unsigned long new_addr, unsigned long old_end, > > > + pmd_t *old_pmd, pmd_t *new_pmd, bool *need_flush) > > > +{ > > > + spinlock_t *old_ptl, *new_ptl; > > > + struct mm_struct *mm = vma->vm_mm; > > > + > > > + if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK) > > > + || old_end - old_addr < PMD_SIZE) > > > + return false; > > > + > > > + /* > > > + * The destination pmd shouldn't be established, free_pgtables() > > > + * should have release it. > > > + */ > > > + if (WARN_ON(!pmd_none(*new_pmd))) > > > + return false; > > > + > > > + /* > > > + * We don't have to worry about the ordering of src and dst > > > + * ptlocks because exclusive mmap_sem prevents deadlock. > > > + */ > > > + old_ptl = pmd_lock(vma->vm_mm, old_pmd); > > > + if (old_ptl) { > > > > How can it ever be false? > > > > > + 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. pmd_lock() cannot fail, but __pmd_trans_huge_lock() can. We should not copy the code blindly. -- Kirill A. Shutemov _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv