From: Balbir Singh <bsingharora@gmail•com>
To: Joel Fernandes <joel@joelfernandes•org>
Cc: linux-mips@linux-mips•org, Rich Felker <dalias@libc•org>,
linux-ia64@vger•kernel.org, linux-sh@vger•kernel.org,
Peter Zijlstra <peterz@infradead•org>,
Catalin Marinas <catalin.marinas@arm•com>,
Dave Hansen <dave.hansen@linux•intel.com>,
Will Deacon <will.deacon@arm•com>,
mhocko@kernel•org, linux-mm@kvack•org, lokeshgidra@google•com,
sparclinux@vger•kernel.org, linux-riscv@lists•infradead.org,
elfring@users•sourceforge.net, Jonas Bonn <jonas@southpole•se>,
kvmarm@lists•cs.columbia.edu, dancol@google•com,
Yoshinori Sato <ysato@users•sourceforge.jp>,
linux-xtensa@linux-xtensa•org, linux-hexagon@vger•kernel.org,
Helge Deller <deller@gmx•de>,
"maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)"
<x86@kernel•org>,
hughd@google•com, "James E.J. Bottomley" <jejb@parisc-linux•org>,
kasan-dev@googlegroups•com, anton.ivanov@kot-begemot•co.uk,
Ingo Molnar <mingo@redhat•com>,
Geert Uytterhoeven <geert@linux-m68k•org>,
Andrey Ryabinin <aryabinin@virtuozzo•com>,
linux-snps-arc@lists•infradead.org, kernel-team@android•com,
Sam Creasey <sammy@sammy•net>, Fenghua Yu <fenghua.yu@intel•com>,
linux-s390@vger•kernel.org, Jeff Dike <jdike@addtoit•com>,
linux-um@lists•infradead.org,
Stefan Kristiansson <stefan.kristiansson@saunalahti•fi>,
Julia Lawall <Julia.Lawall@lip6•fr>,
linux-m68k@lists•linux-m68k.org, Borislav Petkov <bp@alien8•de>,
Andy Lutomirski <luto@kernel•org>,
nios2-dev@lists•rocketboards.org,
"Kirill A. Shutemov" <kirill@shutemov•name>,
Stafford Horne <shorne@gmail•com>, Guan Xuetao <gxt@pku•edu.cn>,
Chris Zankel <chris@zankel•net>, Tony Luck <tony.luck@intel•com>,
Richard Weinberger <richard@nod•at>,
linux-parisc@vger•kernel.org, pantin@google•com,
Max Filippov <jcmvbkbc@gmail•com>,
linux-kernel@vger•kernel.org, minchan@kernel•org,
Thomas Gleixner <tglx@linutronix•de>,
linux-alpha@vger•kernel.org, Ley Foon Tan <lftan@altera•com>,
akpm@linux-foundation•org, linuxppc-dev@lists•ozlabs.org,
"David S. Miller" <davem@davemloft•net>
Subject: Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
Date: Mon, 29 Oct 2018 09:40:02 +1100 [thread overview]
Message-ID: <20181028224002.GA16399@350D> (raw)
In-Reply-To: <20181027193917.GA51131@joelaf.mtv.corp.google.com>
On Sat, Oct 27, 2018 at 12:39:17PM -0700, Joel Fernandes wrote:
> Hi Balbir,
>
> On Sat, Oct 27, 2018 at 09:21:02PM +1100, Balbir Singh wrote:
> > On Wed, Oct 24, 2018 at 07:13:50PM -0700, Joel Fernandes wrote:
> > > On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
> > > [...]
> > > > > > + pmd_t pmd;
> > > > > > +
> > > > > > + new_ptl = pmd_lockptr(mm, new_pmd);
> > > >
> > > >
> > > > Looks like this is largely inspired by move_huge_pmd(), I guess a lot of
> > > > the code applies, why not just reuse as much as possible? The same comments
> > > > w.r.t mmap_sem helping protect against lock order issues applies as well.
> > >
> > > I thought about this and when I looked into it, it seemed there are subtle
> > > differences that make such sharing not worth it (or not possible).
> > >
> >
> > Could you elaborate on them?
>
> The move_huge_page function is defined only for CONFIG_TRANSPARENT_HUGEPAGE
> so we cannot reuse it to begin with, since we have it disabled on our
> systems. I am not sure if it is a good idea to split that out and refactor it
> for reuse especially since our case is quite simple compared to huge pages.
>
> There are also a couple of subtle differences between the move_normal_pmd and
> the move_huge_pmd. Atleast 2 of them are:
>
> 1. We don't concern ourself with the PMD dirty bit, since the pages being
> moved are normal pages and at the soft-dirty bit accounting is at the PTE
> level, since we are not moving PTEs, we don't need to do that.
>
> 2. The locking is simpler as Kirill pointed, pmd_lock cannot fail however
> __pmd_trans_huge_lock can.
>
> I feel it is not super useful to refactor move_huge_pmd to support our case
> especially since move_normal_pmd is quite small, so IMHO the benefit of code
> reuse isn't there very much.
>
My big concern is that any bug fixes will need to monitor both paths.
Do you see a big overhead in checking the soft dirty bit? The locking is
a little different. Having said that, I am not strictly opposed to the
extra code, just concerned about missing fixes/updates as we find them.
> Do let me know your thoughts and thanks for your interest in this.
>
>
Balbir Singh.
next prev parent reply other threads:[~2018-10-28 22:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-13 1:31 [PATCH 0/4] Add support for fast mremap Joel Fernandes (Google)
2018-10-13 1:31 ` [PATCH 1/4] treewide: remove unused address argument from pte_alloc functions (v2) Joel Fernandes (Google)
2018-10-24 8:37 ` Peter Zijlstra
2018-10-25 2:21 ` Joel Fernandes
2018-10-26 8:52 ` Peter Zijlstra
2018-10-25 10:47 ` Kirill A. Shutemov
2018-10-26 8:50 ` Peter Zijlstra
2018-10-13 1:31 ` [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2) Joel Fernandes (Google)
2018-10-15 9:42 ` Christoph Hellwig
2018-10-15 22:33 ` Joel Fernandes
2018-10-16 11:29 ` Vlastimil Babka
2018-10-16 19:43 ` Joel Fernandes
2018-10-17 7:38 ` Vlastimil Babka
2018-10-24 10:12 ` Kirill A. Shutemov
2018-10-24 11:57 ` Balbir Singh
2018-10-24 12:57 ` Kirill A. Shutemov
2018-10-25 2:09 ` Joel Fernandes
2018-10-25 10:19 ` Kirill A. Shutemov
2018-10-26 21:11 ` Joel Fernandes
2018-10-29 10:28 ` Will Deacon
2018-10-25 2:13 ` Joel Fernandes
2018-10-27 10:21 ` Balbir Singh
2018-10-27 19:39 ` Joel Fernandes
2018-10-28 22:40 ` Balbir Singh [this message]
2018-10-13 1:31 ` [PATCH 3/4] arm64: select HAVE_MOVE_PMD for faster mremap (v1) Joel Fernandes (Google)
2018-10-13 1:32 ` [PATCH 4/4] x86: " Joel Fernandes (Google)
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=20181028224002.GA16399@350D \
--to=bsingharora@gmail$(echo .)com \
--cc=Julia.Lawall@lip6$(echo .)fr \
--cc=akpm@linux-foundation$(echo .)org \
--cc=anton.ivanov@kot-begemot$(echo .)co.uk \
--cc=aryabinin@virtuozzo$(echo .)com \
--cc=bp@alien8$(echo .)de \
--cc=catalin.marinas@arm$(echo .)com \
--cc=chris@zankel$(echo .)net \
--cc=dalias@libc$(echo .)org \
--cc=dancol@google$(echo .)com \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=davem@davemloft$(echo .)net \
--cc=deller@gmx$(echo .)de \
--cc=elfring@users$(echo .)sourceforge.net \
--cc=fenghua.yu@intel$(echo .)com \
--cc=geert@linux-m68k$(echo .)org \
--cc=gxt@pku$(echo .)edu.cn \
--cc=hughd@google$(echo .)com \
--cc=jcmvbkbc@gmail$(echo .)com \
--cc=jdike@addtoit$(echo .)com \
--cc=jejb@parisc-linux$(echo .)org \
--cc=joel@joelfernandes$(echo .)org \
--cc=jonas@southpole$(echo .)se \
--cc=kasan-dev@googlegroups$(echo .)com \
--cc=kernel-team@android$(echo .)com \
--cc=kirill@shutemov$(echo .)name \
--cc=kvmarm@lists$(echo .)cs.columbia.edu \
--cc=lftan@altera$(echo .)com \
--cc=linux-alpha@vger$(echo .)kernel.org \
--cc=linux-hexagon@vger$(echo .)kernel.org \
--cc=linux-ia64@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-m68k@lists$(echo .)linux-m68k.org \
--cc=linux-mips@linux-mips$(echo .)org \
--cc=linux-mm@kvack$(echo .)org \
--cc=linux-parisc@vger$(echo .)kernel.org \
--cc=linux-riscv@lists$(echo .)infradead.org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=linux-sh@vger$(echo .)kernel.org \
--cc=linux-snps-arc@lists$(echo .)infradead.org \
--cc=linux-um@lists$(echo .)infradead.org \
--cc=linux-xtensa@linux-xtensa$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=lokeshgidra@google$(echo .)com \
--cc=luto@kernel$(echo .)org \
--cc=mhocko@kernel$(echo .)org \
--cc=minchan@kernel$(echo .)org \
--cc=mingo@redhat$(echo .)com \
--cc=nios2-dev@lists$(echo .)rocketboards.org \
--cc=pantin@google$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=richard@nod$(echo .)at \
--cc=sammy@sammy$(echo .)net \
--cc=shorne@gmail$(echo .)com \
--cc=sparclinux@vger$(echo .)kernel.org \
--cc=stefan.kristiansson@saunalahti$(echo .)fi \
--cc=tglx@linutronix$(echo .)de \
--cc=tony.luck@intel$(echo .)com \
--cc=will.deacon@arm$(echo .)com \
--cc=x86@kernel$(echo .)org \
--cc=ysato@users$(echo .)sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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