Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: joel@joelfernandes.org (Joel Fernandes)
To: linux-riscv@lists.infradead.org
Subject: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > 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

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: David Miller <davem@davemloft.net>
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	mhocko@kernel.org, linux-mm@kvack.org, lokeshgidra@google.com,
	linux-riscv@lists.infradead.org, elfring@users.sourceforge.net,
	jonas@southpole.se, linux-s390@vger.kernel.org,
	dancol@google.com, linux-xtensa@linux-xtensa.org,
	linux-hexagon@vger.kernel.org, deller@gmx.de, hughd@google.com,
	jejb@parisc-linux.org, kasan-dev@googlegroups.com,
	kvmarm@lists.cs.columbia.edu, mingo@redhat.com,
	geert@linux-m68k.org, aryabinin@virtuozzo.com,
	linux-snps-arc@lists.infradead.org, kernel-team@android.com,
	fenghua.yu@intel.com, jdike@addtoit.com,
	linux-um@lists.infradead.org, Julia.Lawall@lip6.fr,
	linux-m68k@lists.linux-m68k.org, bp@alien8.de, luto@kernel.org,
	nios2-dev@lists.rocketboards.org, kirill@shutemov.name,
	gxt@pku.edu.cn, chris@zankel.net, richard@nod.at,
	linux-parisc@vger.kernel.org, pantin@google.com,
	jcmvbkbc@gmail.com, linux-kernel@vger.kernel.org,
	minchan@kernel.org, linux-alpha@vger.kernel.org,
	lftan@altera.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
Date: Fri, 12 Oct 2018 18:35:40 -0700	[thread overview]
Message-ID: <20181013013540.GA207108@joelaf.mtv.corp.google.com> (raw)
Message-ID: <20181013013540.zhw7pjSjxg_Yzfa-wrqun3Ju9Sz-LXVTIifv_9oNCEA@z> (raw)
In-Reply-To: <20181012.111836.1569129998592378186.davem@davemloft.net>

On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes <joel@joelfernandes.org>
[...]
> > 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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2018-10-13  1:35 UTC|newest]

Thread overview: 76+ 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 ` 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  1:37   ` Joel Fernandes (Google)
2018-10-12 11:30   ` Kirill A. Shutemov
2018-10-12 11:30     ` Kirill A. Shutemov
2018-10-12 11:36     ` Kirill A. Shutemov
2018-10-12 11:36       ` Kirill A. Shutemov
2018-10-12 12:50     ` Joel Fernandes
2018-10-12 12:50       ` Joel Fernandes
2018-10-12 13:19       ` Kirill A. Shutemov
2018-10-12 13:19         ` Kirill A. Shutemov
2018-10-12 16:57         ` Joel Fernandes
2018-10-12 16:57           ` Joel Fernandes
2018-10-12 21:33           ` Kirill A. Shutemov
2018-10-12 21:33             ` Kirill A. Shutemov
2018-10-12 18:18       ` David Miller
2018-10-12 18:18         ` David Miller
2018-10-13  1:35         ` Joel Fernandes [this message]
2018-10-13  1:35           ` Joel Fernandes
2018-10-13  1:39           ` Daniel Colascione
2018-10-13  1:39             ` Daniel Colascione
2018-10-13  1:44             ` Joel Fernandes
2018-10-13  1:44               ` Joel Fernandes
2018-10-13  1:54               ` Daniel Colascione
2018-10-13  1:54                 ` Daniel Colascione
2018-10-13  2:10                 ` Joel Fernandes
2018-10-13  2:10                   ` Joel Fernandes
2018-10-13  2:25                   ` Daniel Colascione
2018-10-13  2:25                     ` Daniel Colascione
2018-10-13 17:50                     ` Joel Fernandes
2018-10-13 17:50                       ` Joel Fernandes
2018-10-12 18:02     ` David Miller
2018-10-12 18:02       ` David Miller
2018-10-12 14:09   ` Anton Ivanov
2018-10-12 14:09     ` Anton Ivanov
2018-10-12 14:37     ` Kirill A. Shutemov
2018-10-12 14:37       ` Kirill A. Shutemov
2018-10-12 14:48       ` Anton Ivanov
2018-10-12 14:48         ` Anton Ivanov
2018-10-12 16:42         ` Anton Ivanov
2018-10-12 16:42           ` Anton Ivanov
2018-10-12 16:50           ` Joel Fernandes
2018-10-12 16:50             ` Joel Fernandes
2018-10-12 16:58             ` Anton Ivanov
2018-10-12 16:58               ` Anton Ivanov
2018-10-12 17:06               ` Joel Fernandes
2018-10-12 17:06                 ` Joel Fernandes
2018-10-12 21:40           ` Kirill A. Shutemov
2018-10-12 21:40             ` Kirill A. Shutemov
2018-10-13  6:10             ` Anton Ivanov
2018-10-13  6:10               ` Anton Ivanov
2018-10-15  7:10   ` Christian Borntraeger
2018-10-15  7:10     ` Christian Borntraeger
2018-10-15  8:18     ` Martin Schwidefsky
2018-10-15  8:18       ` Martin Schwidefsky
2018-10-16  2:08       ` Joel Fernandes
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 11:09   ` Kirill A. Shutemov
2018-10-12 16:37   ` Joel Fernandes
2018-10-12 16:37     ` Joel Fernandes
2018-10-12 13:56 ` Anton Ivanov
2018-10-12 13:56   ` Anton Ivanov
2018-10-12 16:34   ` Joel Fernandes
2018-10-12 16:34     ` Joel Fernandes
2018-10-12 16:38     ` Julia Lawall
2018-10-12 16:38       ` Julia Lawall
2018-10-12 16:46       ` Joel Fernandes
2018-10-12 16:46         ` Joel Fernandes
2018-10-12 18:51 ` SF Markus Elfring
2018-10-12 18:51   ` SF Markus Elfring
2018-10-12 19:42   ` Joel Fernandes
2018-10-12 19:42     ` Joel Fernandes
2018-10-13  9:22     ` SF Markus Elfring
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=20181013013540.GA207108@joelaf.mtv.corp.google.com \
    --to=joel@joelfernandes.org \
    --cc=linux-riscv@lists.infradead.org \
    /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