linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: dancol@google.com
Cc: David Miller <davem@davemloft.net>,
	kirill@shutemov.name, linux-kernel <linux-kernel@vger.kernel.org>,
	kernel-team@android.com, Minchan Kim <minchan@kernel.org>,
	Ramon Pantin <pantin@google.com>, Hugh Dickins <hughd@google.com>,
	Lokesh Gidra <lokeshgidra@google.com>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de,
	catalin.marinas@arm.com, Chris Zankel <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 Bonn <jonas@southpole.se>,
	Julia Lawall <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-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 <jcmvbkbc@gmail.com>,
	nios2-dev@lists.rocketboards.org,
	Peter Zijlstra <peterz@infradead.org>,
	richard@nod.at
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Sat, 13 Oct 2018 10:50:39 -0700	[thread overview]
Message-ID: <20181013175039.GB213522@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <CAKOZueu2wdkeUFYLQ8qE48yJs1_uRz-9RVJRkp==CL=jp=Q8+g@mail.gmail.com>

On Fri, Oct 12, 2018 at 07:25:08PM -0700, Daniel Colascione wrote:
[...] 
> > But anyway, I think this runtime detection thing is not needed. THP is
> > actually expected to be as fast as this anyway, so if that's available then
> > we should already be as fast.
> 
> Ah, I think the commit message is confusing. (Or else I'm misreading
> the patch now.) It's not quite that we're disabling the feature when
> THP is enabled anywhere, but rather that we use the move_huge_pmd path
> for huge PMDs and use the new code only for non-huge PMDs. (Right?) If
> that's the case, the commit message shouldn't say "Incase THP is
> enabled, the optimization is skipped". Even if THP is enabled on a
> system generally, we might use the new PMD-moving code for mapping
> types that don't support THP-ization, right?

That is true. Ok, I guess I can update the commit message to be more accurate
about that.

> > This is for non-THP where THP cannot be enabled
> > and there is still room for some improvement. Most/all architectures will be
> > just fine with this. This flag is more of a safety-net type of thing where in
> > the future if there is this one or two weird architectures that don't play
> > well, then they can turn it off at the architecture level by not selecting
> > the flag. See my latest patches for the per-architecture compile-time
> > controls. Ideally we'd like to blanket turn it on on all, but this is just
> > playing it extra safe as Kirill and me were discussing on other threads.
> 
> Sure. I'm just pointing out that the 500x performance different turns
> the operation into a qualitatively different feature, so if we expect
> to actually ship a mainstream architecture without support for this
> thing, we should make it explicit. If we're not, we shouldn't.

We can make it explicit by enabling it in such a mainstream architecture is
my point. Also if the optimization is not doing what its supposed to, then
userspace will also just know by measuring the time.

thanks,

 - Joel

  reply	other threads:[~2018-10-13 17:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12  1:37 [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions Joel Fernandes (Google)
2018-10-12  1:37 ` [PATCH v2 2/2] mm: speed up mremap by 500x on large regions Joel Fernandes (Google)
2018-10-12 11:30   ` Kirill A. Shutemov
2018-10-12 11:36     ` Kirill A. Shutemov
2018-10-12 12:50     ` Joel Fernandes
2018-10-12 13:19       ` Kirill A. Shutemov
2018-10-12 16:57         ` Joel Fernandes
2018-10-12 21:33           ` Kirill A. Shutemov
2018-10-12 18:18       ` David Miller
2018-10-13  1:35         ` Joel Fernandes
2018-10-13  1:39           ` Daniel Colascione
2018-10-13  1:44             ` Joel Fernandes
2018-10-13  1:54               ` Daniel Colascione
2018-10-13  2:10                 ` Joel Fernandes
2018-10-13  2:25                   ` Daniel Colascione
2018-10-13 17:50                     ` Joel Fernandes [this message]
2018-10-12 18:02     ` David Miller
2018-10-12 14:09   ` Anton Ivanov
2018-10-12 14:37     ` Kirill A. Shutemov
2018-10-12 14:48       ` Anton Ivanov
2018-10-12 16:42         ` Anton Ivanov
2018-10-12 16:50           ` Joel Fernandes
2018-10-12 16:58             ` Anton Ivanov
2018-10-12 17:06               ` Joel Fernandes
2018-10-12 21:40           ` Kirill A. Shutemov
2018-10-13  6:10             ` Anton Ivanov
2018-10-15  7:10   ` Christian Borntraeger
2018-10-15  8:18     ` Martin Schwidefsky
2018-10-16  2:08       ` Joel Fernandes
2018-10-12 11:09 ` [PATCH v2 1/2] treewide: remove unused address argument from pte_alloc functions Kirill A. Shutemov
2018-10-12 16:37   ` Joel Fernandes
2018-10-12 13:56 ` Anton Ivanov
2018-10-12 16:34   ` Joel Fernandes
2018-10-12 16:38     ` Julia Lawall
2018-10-12 16:46       ` Joel Fernandes
2018-10-12 18:51 ` SF Markus Elfring
2018-10-12 19:42   ` Joel Fernandes
2018-10-13  9:22     ` SF Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181013175039.GB213522@joelaf.mtv.corp.google.com \
    --to=joel@joelfernandes.org \
    --cc=Julia.Lawall@lip6.fr \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chris@zankel.net \
    --cc=dancol@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=elfring@users.sourceforge.net \
    --cc=fenghua.yu@intel.com \
    --cc=geert@linux-m68k.org \
    --cc=gxt@pku.edu.cn \
    --cc=hughd@google.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jdike@addtoit.com \
    --cc=jejb@parisc-linux.org \
    --cc=jonas@southpole.se \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel-team@android.com \
    --cc=kirill@shutemov.name \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=lftan@altera.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lokeshgidra@google.com \
    --cc=luto@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nios2-dev@lists.rocketboards.org \
    --cc=pantin@google.com \
    --cc=peterz@infradead.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox