From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 2453B6EC55; Tue, 27 Jul 2021 18:47:02 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2453B6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1627400822; bh=dlpgElpIqB8ICzdqvq6XgjmCIC7T4geAnvTO45ypEYM=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=hyKxGyxq1YmnoIHaE60fs87nlYs+OaXNhlzkwdnvZvNfyTh12btvz5KvnsFHShn8Y pTbhexxOLkUBCIm51YiU0M1C2dG2GQ12j2k3/L27vCrXf22+m5f28iXLeBArkvurfg zpeTCPcbETaQJOVqO8a0AIS6miZigWhS59dsan1I= Received: from smtpng2.i.mail.ru (smtpng2.i.mail.ru [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 16F9A6EC55 for ; Tue, 27 Jul 2021 18:47:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 16F9A6EC55 Received: by smtpng2.m.smailru.net with esmtpa (envelope-from ) id 1m8PII-0001c9-Tq; Tue, 27 Jul 2021 18:46:59 +0300 Date: Tue, 27 Jul 2021 18:23:23 +0300 To: Sergey Kaplun Message-ID: <20210727152323.GS27855@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) X-4EC0790: 10 X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD941C43E597735A9C34755E0A9F196FCB739C645213AB7C8E0182A05F5380850406E9F76B667795777CC3E2B03545FF273CCEE257A919687B8BD38AD036528B2EF X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7A40BF27E8345D582EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375448D590B04CE87D8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D841393D23CC22DA4669E9F07EE23930B9117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18CB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B67393CE827C55B5F775ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A5B33C87FCB9AE93E3615AF3DDACAADC82BBE3586EA07B56F5D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75FA7FF33AA1A4D21C410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34D4E96E2A5B1100E0015B1BB029FF2BEAE65C9AF467FE7A28B79365699D050757AF3D3021D9764D261D7E09C32AA3244C2F2AF552186BF3A68EBBCAA61949C5E9435BF7150578642F927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojiF1u9eOpfTSHuWVK3YKXjQ== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D017160FCD249D605A470D456EA8F6088A7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 2/2] Linux/ARM64: Make mremap() non-moving due to VA space woes. X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey, Thanks for the patch! LGTM, except a few nits below. On 06.07.21, Sergey Kaplun wrote: > From: Mike Pall > > 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 > > 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