From: Igor Munkin via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Sergey Kaplun <skaplun@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes. Date: Tue, 27 Jul 2021 18:23:23 +0300 [thread overview] Message-ID: <20210727152323.GS27855@tarantool.org> (raw) In-Reply-To: <c04ec11ad17902359194966315cd6cfa81f8bd45.1625587322.git.skaplun@tarantool.org> Sergey, Thanks for the patch! LGTM, except a few nits below. On 06.07.21, Sergey Kaplun wrote: > From: Mike Pall <mike> > > This reduces overall performance on ARM64, but we have no choice. > Linux kernel default userspace VA is 48 bit, but we'd need 47 bit. > mremap() ignores address hints due to a kernel API issue. The mapping > may move to an undesired address which will cause an assert or crash. > > Reported by Raymond W. Ko. > > (cherry picked from commit 67dbec82f4f05a416a78a560a726553beaa7a223) > > 47-bit VA space is required by LuaJIT for keeping a GC object pointer in > TValue. When need to reallocate to huge sized block `mrepmap()` on arm64 > may move out VA space from the 47-bit range. `mremap()` accepts the I'd rather reword the previous sentence the following way: | In case of huge blobs that are mapped directly, `mremap()` may move | the chunk out of 47-bit range of VA space on ARM64. > fifth argument (new address hint) only with MREMAP_FIXED flag. In that > case it unmaps any other mapping to specified address. > > To avoid this behaviour this patch restricts `mremap()` to relocate > the mapping to a new virtual address by reset MREMAP_MAYMOVE flag I'm confused a bit with "reset" word: MREMAP_MAYMOVE is simply changed to 0 (i.e. CALL_MREMAP_NOMOVE). Moreover, it's better to stay in LuaJIT terms instead of Linux ones. > for arm64 architecture. > > Sergey Kaplun: > * added the description and the test for the problem > > Needed for tarantool/tarantool#6154 > --- > src/lj_alloc.c | 2 +- > .../lj-671-arm64-assert-after-mremap.test.lua | 24 +++++++++++++++++++ > 2 files changed, 25 insertions(+), 1 deletion(-) > create mode 100644 test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua > <snipped> > diff --git a/test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua b/test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua > new file mode 100644 > index 00000000..0be60a2d > --- /dev/null > +++ b/test/tarantool-tests/lj-671-arm64-assert-after-mremap.test.lua > @@ -0,0 +1,24 @@ > +local tap = require('tap') > + > +-- Test file to demonstrate assertion after `mremap()` on arm64. > +-- See also, https://github.com/LuaJIT/LuaJIT/issues/671. > + > +local test = tap.test('lj-671-arm64-assert-after-mremap') > +test:plan(1) > + > +-- `mremap()` is used on Linux for remap directly mapped big Typo: s/for/to/. > +-- (>=DEFAULT_MMAP_THRESHOLD) memory chunks. > +-- The simplest way to test memory move is to allocate the huge > +-- memory chunk for string buffer directly and reallocate it > +-- after. > +-- To allocate buffer exactly to threshold limit for direct chunk > +-- mapping use `string.rep()` with length equals threshold. > +-- Then concatenate result string (with length of > +-- DEFAULT_MMAP_THRESHOLD) with the other one to reallocate > +-- and remap string buffer. Just polished two sections above: | -- To allocate a memory buffer with the size up to the threshold | -- for direct mapping `string.rep()` is used with the length that | -- equals to DEFAULT_MMAP_THRESHOLD. | -- Then concatenate the directly mapped result string with the | -- other one to trigger buffer reallocation and its remapping. > + > +local DEFAULT_MMAP_THRESHOLD = 128 * 1024 > +local s = string.rep('x', DEFAULT_MMAP_THRESHOLD)..'x' > +test:ok(s) > + > +os.exit(test:check() and 0 or 1) > -- > 2.31.0 > -- Best regards, IM
next prev parent reply other threads:[~2021-07-27 15:47 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-06 17:40 [Tarantool-patches] [PATCH luajit 0/2] arm64: fix 48-bit addresses issues Sergey Kaplun via Tarantool-patches 2021-07-06 17:40 ` [Tarantool-patches] [PATCH luajit 1/2] Add support for full-range 64 bit lightuserdata Sergey Kaplun via Tarantool-patches 2021-07-27 13:59 ` Igor Munkin via Tarantool-patches 2021-07-28 12:29 ` Sergey Kaplun via Tarantool-patches 2021-08-01 10:36 ` Igor Munkin via Tarantool-patches 2021-08-02 14:56 ` Sergey Kaplun via Tarantool-patches 2021-08-01 16:25 ` Sergey Ostanevich via Tarantool-patches 2021-08-02 14:51 ` Sergey Kaplun via Tarantool-patches 2021-08-02 15:42 ` Igor Munkin via Tarantool-patches 2021-08-10 16:46 ` Sergey Ostanevich via Tarantool-patches 2021-08-11 5:54 ` Vitaliia Ioffe via Tarantool-patches 2021-07-06 17:40 ` [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes Sergey Kaplun via Tarantool-patches 2021-07-27 15:23 ` Igor Munkin via Tarantool-patches [this message] 2021-07-28 12:29 ` Sergey Kaplun via Tarantool-patches 2021-08-01 10:36 ` Igor Munkin via Tarantool-patches 2021-08-01 16:59 ` Sergey Ostanevich via Tarantool-patches 2021-08-02 15:08 ` Sergey Kaplun via Tarantool-patches 2021-08-02 15:55 ` Sergey Ostanevich via Tarantool-patches 2021-08-02 15:11 ` Sergey Kaplun via Tarantool-patches 2021-08-11 7:21 ` [Tarantool-patches] [PATCH luajit 0/2] arm64: fix 48-bit addresses issues Igor Munkin via Tarantool-patches
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=20210727152323.GS27855@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=imun@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes.' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox