From: Kalesh Singh <kaleshsingh@google.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Suren Baghdasaryan <surenb@google.com>,
Minchan Kim <minchan@google.com>,
Joel Fernandes <joelaf@google.com>,
Lokesh Gidra <lokeshgidra@google.com>,
"Cc: Android Kernel" <kernel-team@android.com>,
kernel test robot <lkp@intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"the arch/x86 maintainers" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Shuah Khan <shuah@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Kees Cook <keescook@chromium.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Sami Tolvanen <samitolvanen@google.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Frederic Weisbecker <frederic@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Hassan Naveed <hnaveed@wavecomp.com>,
Christian Brauner <christian.brauner@ubuntu.com>,
Stephen Boyd <sboyd@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Gavin Shan <gshan@redhat.com>, Mike Rapoport <rppt@kernel.org>,
Steven Price <steven.price@arm.com>, Jia He <justin.he@arm.com>,
John Hubbard <jhubbard@nvidia.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Yang Shi <yang.shi@linux.alibaba.com>,
Mina Almasry <almasrymina@google.com>,
Ralph Campbell <rcampbell@nvidia.com>,
Ram Pai <linuxram@us.ibm.com>,
Sandipan Das <sandipan@linux.ibm.com>,
Dave Hansen <dave.hansen@intel.com>,
Brian Geffon <bgeffon@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Ira Weiny <ira.weiny@intel.com>, SeongJae Park <sjpark@amazon.de>,
LKML <linux-kernel@vger.kernel.org>,
"moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
<linux-arm-kernel@lists.infradead.org>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH v4 3/5] mm: Speedup mremap on 1GB or larger regions
Date: Thu, 17 Dec 2020 13:15:54 -0500 [thread overview]
Message-ID: <CAC_TJvenGcLUnNE2sG4yBfcp_Aw3mg+cXWN2-nRyzj09bznMyQ@mail.gmail.com> (raw)
In-Reply-To: <20201217172847.GA89104@roeck-us.net>
On Thu, Dec 17, 2020 at 12:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Oct 14, 2020 at 12:53:08AM +0000, Kalesh Singh wrote:
> > Android needs to move large memory regions for garbage collection.
> > The GC requires moving physical pages of multi-gigabyte heap
> > using mremap. During this move, the application threads have to
> > be paused for correctness. It is critical to keep this pause as
> > short as possible to avoid jitters during user interaction.
> >
> > Optimize mremap for >= 1GB-sized regions by moving at the PUD/PGD
> > level if the source and destination addresses are PUD-aligned.
> > For CONFIG_PGTABLE_LEVELS == 3, moving at the PUD level in effect moves
> > PGD entries, since the PUD entry is “folded back” onto the PGD entry.
> > Add HAVE_MOVE_PUD so that architectures where moving at the PUD level
> > isn't supported/tested can turn this off by not selecting the config.
> >
> > Fix build test error from v1 of this series reported by
> > kernel test robot in [1].
> >
> > [1] https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/CKPGL4FH4NG7TGH2CVYX2UX76L25BTA3/
> >
> > Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
> > Reported-by: kernel test robot <lkp@intel.com>
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
>
> I thought I reported it, but maybe I didn't. This patch causes all
> 'parisc' qemu emulations to fail. Typical log:
>
> Freeing unused kernel memory: 604K
> Write protected read-only-after-init data: 2k
> rodata_test: end of .rodata is not page size aligned
> Run /sbin/init as init process
> process '/bin/busybox' started with executable stack
> Failed to execute /sbin/init (error -12)
>
> Reverting this patch fixes the problem.
>
> Bisect log from linux-next below. The patch (and thus the problem)
> are now in mainline Linux.
Hi Guenter,
Thanks for reporting. We enabled this on x86 and arm64. Investigating
what the root cause is now.
Kalesh
>
> Guenter
>
> ---
> # bad: [7bba37a1591369e2e506d599b8f5d7d0516b2dbc] Add linux-next specific files for 20201214
> # good: [0477e92881850d44910a7e94fc2c46f96faa131f] Linux 5.10-rc7
> git bisect start 'HEAD' 'v5.10-rc7'
> # good: [fe5c40ab90a1f82ba97294637eaf875cfdd7a05f] Merge remote-tracking branch 'nand/nand/next'
> git bisect good fe5c40ab90a1f82ba97294637eaf875cfdd7a05f
> # good: [674a0d6de8bd290671f7dff405205871a70300b3] Merge remote-tracking branch 'spi/for-next'
> git bisect good 674a0d6de8bd290671f7dff405205871a70300b3
> # good: [8623dae312f73a2ea3230b1c648d3004cfc224ce] Merge remote-tracking branch 'vfio/next'
> git bisect good 8623dae312f73a2ea3230b1c648d3004cfc224ce
> # good: [dd26635f54bcd8e5d4e875a209f82a0423ba9c08] Merge remote-tracking branch 'gpio/for-next'
> git bisect good dd26635f54bcd8e5d4e875a209f82a0423ba9c08
> # good: [86e9c9a734889fe437442e0a35eb4c61d319cb47] Merge remote-tracking branch 'memblock/for-next'
> git bisect good 86e9c9a734889fe437442e0a35eb4c61d319cb47
> # bad: [3452331fda80b1cb5e121e6718ca6c07264382b2] userfaultfd: add user-mode only option to unprivileged_userfaultfd sysctl knob
> git bisect bad 3452331fda80b1cb5e121e6718ca6c07264382b2
> # bad: [19f468d54fcffc3f98b71e3e12ff23726767d953] mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio
> git bisect bad 19f468d54fcffc3f98b71e3e12ff23726767d953
> # good: [d89f3ababcac54493a4cb0582c61eb5f426b44e3] mm: remove pagevec_lookup_range_nr_tag()
> git bisect good d89f3ababcac54493a4cb0582c61eb5f426b44e3
> # good: [eba8373dcb40d30952f31d5fc0cff56b78f46273] mm/mlock: remove __munlock_isolate_lru_page()
> git bisect good eba8373dcb40d30952f31d5fc0cff56b78f46273
> # good: [8831d3f3564beba0f3f1b5291c88b35725bc45c9] xen/unpopulated-alloc: consolidate pgmap manipulation
> git bisect good 8831d3f3564beba0f3f1b5291c88b35725bc45c9
> # bad: [b8d53d70851821d8a2040ddca3aa6ee88fc8aaec] mm/page_vma_mapped.c: add colon to fix kernel-doc markups error for check_pte
> git bisect bad b8d53d70851821d8a2040ddca3aa6ee88fc8aaec
> # bad: [e77846c3da1862faa25c08e186a62b03e98c862f] x86: mremap speedup - Enable HAVE_MOVE_PUD
> git bisect bad e77846c3da1862faa25c08e186a62b03e98c862f
> # bad: [72ad8951bac1c559ea1b691a0b035fb339e4d71d] mm: speedup mremap on 1GB or larger regions
> git bisect bad 72ad8951bac1c559ea1b691a0b035fb339e4d71d
> # good: [fa94bfe31609787501a1ff8d7659ade5734ec4e5] kselftests: vm: add mremap tests
> git bisect good fa94bfe31609787501a1ff8d7659ade5734ec4e5
> # first bad commit: [72ad8951bac1c559ea1b691a0b035fb339e4d71d] mm: speedup mremap on 1GB or larger regions
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>
next prev parent reply other threads:[~2020-12-17 18:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 0:53 [PATCH v4 0/5] Speed up mremap on large regions Kalesh Singh
2020-10-14 0:53 ` [PATCH v4 1/5] kselftests: vm: Add mremap tests Kalesh Singh
2020-10-14 19:02 ` Kalesh Singh
2020-10-14 0:53 ` [PATCH v4 2/5] arm64: mremap speedup - Enable HAVE_MOVE_PMD Kalesh Singh
2020-10-15 10:55 ` Will Deacon
2020-10-14 0:53 ` [PATCH v4 3/5] mm: Speedup mremap on 1GB or larger regions Kalesh Singh
2020-12-17 17:28 ` Guenter Roeck
2020-12-17 18:15 ` Kalesh Singh [this message]
2020-10-14 0:53 ` [PATCH v4 4/5] arm64: mremap speedup - Enable HAVE_MOVE_PUD Kalesh Singh
2020-10-14 0:53 ` [PATCH v4 5/5] x86: " Kalesh Singh
2020-10-14 15:53 ` Ingo Molnar
2020-10-15 20:40 ` [PATCH v4 0/5] Speed up mremap on large regions Will Deacon
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=CAC_TJvenGcLUnNE2sG4yBfcp_Aw3mg+cXWN2-nRyzj09bznMyQ@mail.gmail.com \
--to=kaleshsingh@google.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=anshuman.khandual@arm.com \
--cc=arnd@arndb.de \
--cc=bgeffon@google.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christian.brauner@ubuntu.com \
--cc=dave.hansen@intel.com \
--cc=frederic@kernel.org \
--cc=gshan@redhat.com \
--cc=hnaveed@wavecomp.com \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joelaf@google.com \
--cc=jpoimboe@redhat.com \
--cc=justin.he@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@roeck-us.net \
--cc=linuxram@us.ibm.com \
--cc=lkp@intel.com \
--cc=lokeshgidra@google.com \
--cc=masahiroy@kernel.org \
--cc=mhiramat@kernel.org \
--cc=minchan@google.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rcampbell@nvidia.com \
--cc=rppt@kernel.org \
--cc=samitolvanen@google.com \
--cc=sandipan@linux.ibm.com \
--cc=sboyd@kernel.org \
--cc=shuah@kernel.org \
--cc=sjpark@amazon.de \
--cc=steven.price@arm.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yang.shi@linux.alibaba.com \
/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;
as well as URLs for NNTP newsgroup(s).