From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by kanga.kvack.org (Postfix) with ESMTP id 2CC016B026C for ; Fri, 12 Oct 2018 21:39:48 -0400 (EDT) Received: by mail-io1-f72.google.com with SMTP id c5-v6so12924963ioa.0 for ; Fri, 12 Oct 2018 18:39:48 -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 i1-v6sor1611111ioh.3.2018.10.12.18.39.47 for (Google Transport Security); Fri, 12 Oct 2018 18:39:47 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20181013013540.GA207108@joelaf.mtv.corp.google.com> References: <20181012013756.11285-2-joel@joelfernandes.org> <20181012113056.gxhcbrqyu7k7xnyv@kshutemo-mobl1> <20181012125046.GA170912@joelaf.mtv.corp.google.com> <20181012.111836.1569129998592378186.davem@davemloft.net> <20181013013540.GA207108@joelaf.mtv.corp.google.com> From: Daniel Colascione Date: Fri, 12 Oct 2018 18:39:45 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Joel Fernandes Cc: David Miller , kirill@shutemov.name, linux-kernel , kernel-team@android.com, Minchan Kim , Ramon Pantin , hughd@google.com, Lokesh Gidra , Michal Hocko , Andrew Morton , aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de, catalin.marinas@arm.com, chris@zankel.net, dave.hansen@linux.intel.com, elfring@users.sourceforge.net, fenghua.yu@intel.com, geert@linux-m68k.org, gxt@pku.edu.cn, deller@gmx.de, mingo@redhat.com, jejb@parisc-linux.org, jdike@addtoit.com, jonas@southpole.se, Julia.Lawall@lip6.fr, kasan-dev@googlegroups.com, kvmarm@lists.cs.columbia.edu, lftan@altera.com, 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 , 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, jcmvbkbc@gmail.com, nios2-dev@lists.rocketboards.org, Peter Zijlstra , richard@nod.at Not 32-bit ARM? On Fri, Oct 12, 2018 at 6:35 PM, Joel Fernandes wrote: > On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote: >> From: Joel Fernandes > [...] >> > Also, do we not flush the caches from any path when we munmap >> > address space? We do call do_munmap on the old mapping from mremap >> > after moving to the new one. >> >> Sparc makes sure that shared mapping have consistent colors. Therefore >> all that's left are private mappings and those will be initialized by >> block stores to clear the page out or similar. >> >> Also, when creating new mappings, we flush the D-cache when necessary >> in update_mmu_cache(). >> >> We also maintain a bit in the page struct to track when a page which >> was potentially written to on one cpu ends up mapped into another >> address space and flush as necessary. >> >> The cache is write-through, which simplifies the preconditions we have >> to maintain. > > Makes sense, thanks. For the moment I sent patches to enable this on arm64 > and x86. We can enable it on sparc as well at a later time as it sounds it > could be a safe optimization to apply to that architecture as well. > > thanks, > > - Joel >