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 C4BD66EC58; Mon, 2 Aug 2021 18:09:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C4BD66EC58 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1627916992; bh=c8Pg60gcuI5YYa00a0DJJzXIMxLjV3OEuiaUZPHvHdY=; 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=RcXoKVzoRC4uBdAifhLUrabQzG7we1QSEeTQnizN3s28BPoUBCHPEcwQVChJ7N9sg Hf1jy10LPxgqfDo6rsiYWdksnt94uTlbQEA9utRxZVz7Szr61PTQTFpUgorGCaACwp 89q0qFLZigvgA+f4MNd9msSV5wsuufqwL9qdpgPQ= Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (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 F0B866EC58 for ; Mon, 2 Aug 2021 18:09:51 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org F0B866EC58 Received: by smtp41.i.mail.ru with esmtpa (envelope-from ) id 1mAZZf-0001wc-1Z; Mon, 02 Aug 2021 18:09:51 +0300 Date: Mon, 2 Aug 2021 18:08:37 +0300 To: Sergey Ostanevich Message-ID: References: <20210727152323.GS27855@tarantool.org> <20210801103633.GX27855@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-4EC0790: 10 X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD941C43E597735A9C3FDAB68B812060C77E97CF8617D978122182A05F538085040F99BA03C1497FFF9FE887BE4523BCFF66F491DFD246347BF4F9E84A553C9351C X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE75012335B19220D49EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637B24541F05F0BFC9F8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D898A3C8F0491DA322C2559FEC129B5E5C117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18BDFBBEFFF4125B51D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B613439FA09F3DCB32089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5B49A7CBCFB107AEF466237D4F126176EEB9DCF1FEE257F2BD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA751B940EDA0DFB0535410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3498910055B812BD9CF746C7C4945E7BA7047A62F65B2F89A1C5DA1EE3FE6D20C112296999450178831D7E09C32AA3244C862E92E92291EDDE4E754711FCBF742963871F383B54D9B3FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj9N286KAyvN4/pT0Oji4+jw== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB4F7C61FAAFDE2FFF0E7BF067C7BDDA73841611919824C70C7F2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 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: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Sergos! Thanks for the review! On 01.08.21, Sergey Ostanevich wrote: > Hi! Thanks for the patch! > > Now direct_resize() will fail if it doesn't fit into the current place > with a new size and a direct_alloc() supposedly will be called. This one > doesn't help with 47-bit address AFAIU since it has no extra option - > I doubt it exist at all - to ask kernel to fit. > > So, how it helps? For arm64 LJ_64 mode is enabled. It means LJ_ALLOC_MMAP_PROBE is defined and for each huge allocation `mmap_probe()` is called. This function tries several allocations unless the limit (30) is reached, or any suitable address is found. > > > Regards, > Sergos > > > > On 1 Aug 2021, at 13:36, Igor Munkin wrote: > > > > Sergey, > > > > Thanks for the fixes! LGTM, except the single typo. > > > > On 28.07.21, Sergey Kaplun wrote: > > > > > > > >> > >> The new commit message is the following: > >> > >> =================================================================== > >> Linux/ARM64: Make mremap() non-moving due to VA space woes. > >> > >> 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. In case of huge blobs that are mapped directly, `mremap()` may > >> move the chunk out of 47-bit range of VA space on ARM64. `mremap()` > >> accepts the 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 set CALL_MREMAP_NOMOVE flag > > > > Typo: s/set/setting/. > > > >> instead of CALL_MREMAP_MAYMOVE for arm64 architecture. > >> > >> Sergey Kaplun: > >> * added the description and the test for the problem > >> > >> Needed for tarantool/tarantool#6154 > > > > Minor: Why #5629 is not mentioned? > > > >> =================================================================== > >> > > > > > > > >> > >> -- > >> Best regards, > >> Sergey Kaplun > > > > -- > > Best regards, > > IM > -- Best regards, Sergey Kaplun