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
next prev 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