From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by kanga.kvack.org (Postfix) with ESMTP id 3F3986B0271 for ; Fri, 12 Oct 2018 21:54:36 -0400 (EDT) Received: by mail-ot1-f70.google.com with SMTP id c46so9863664otd.0 for ; Fri, 12 Oct 2018 18:54:36 -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 o27sor1807437oth.20.2018.10.12.18.54.35 for (Google Transport Security); Fri, 12 Oct 2018 18:54:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20181013014429.GB207108@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> <20181013014429.GB207108@joelaf.mtv.corp.google.com> From: Daniel Colascione Date: Fri, 12 Oct 2018 18:54:33 -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 I wonder whether it makes sense to expose to userspace somehow whether mremap is "fast" for a particular architecture. If a feature relies on fast mremap, it might be better for some userland component to disable that feature entirely rather than blindly use mremap and end up performing very poorly. If we're disabling fast mremap when THP is enabled, the userland component can't just rely on an architecture switch and some kind of runtime feature detection becomes even more important. On Fri, Oct 12, 2018 at 6:44 PM, Joel Fernandes wrote: > On Fri, Oct 12, 2018 at 06:39:45PM -0700, Daniel Colascione wrote: >> Not 32-bit ARM? > > Well, I didn't want to enable every possible architecture we could in a > single go. Certainly arm32 can be a follow on enablement as can be other > architectures. The point of this series is to upstream this feature and > enable a hand-picked few architectures as a first step. > > thanks, > > - Joel >