From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60518C3ABBC for ; Fri, 9 May 2025 05:27:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 024876B0088; Fri, 9 May 2025 01:27:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F17DD6B0089; Fri, 9 May 2025 01:27:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE0636B008A; Fri, 9 May 2025 01:27:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B99686B0088 for ; Fri, 9 May 2025 01:27:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1BAB4140671 for ; Fri, 9 May 2025 05:27:18 +0000 (UTC) X-FDA: 83422236156.08.7C83AE0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 57759180010 for ; Fri, 9 May 2025 05:27:16 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf06.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746768436; a=rsa-sha256; cv=none; b=st71AofxmA6XvJpAy9cowhTLhRzNBVsOLlhzS1S2GauM9zOHoWNaljV4N08mx26Wu2Wsw6 GBSI0rLTP9hCbcGfL9+jVVDeCUojQvzvf7C694E5R83atdowHew1qsxgA2xLK3BtF8lJ5S 9SqOUpamqyVcEuhJ78Coif2zVqA7Igc= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf06.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746768436; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9JDMduHsaxeiP26qOQL0ckUn4YJj8bMJaQRFOTTyL5Q=; b=sesDOYCnVPseNZp2wXsp6bSmDDv7RvfED294615iQEt7X4kgm67ipGJ1CGyzb0baJvV+fX 2SUU8s8cH26PI1hOlgNLmvwS9JIBHoFfyRDnMwefNCYcIMZBp0OSdsB5hPgdukmFKWn58M uZN7fGfAdGDPwzEoGVwhIVakp0PAFng= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EEE91153B; Thu, 8 May 2025 22:27:04 -0700 (PDT) Received: from [10.162.43.14] (K4MQJ0H1H2.blr.arm.com [10.162.43.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8172C3F58B; Thu, 8 May 2025 22:27:08 -0700 (PDT) Message-ID: Date: Fri, 9 May 2025 10:57:05 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/2] Optimize mremap() for large folios To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, vbabka@suse.cz, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@redhat.com, peterx@redhat.com, ryan.roberts@arm.com, mingo@kernel.org, libang.li@antgroup.com, maobibo@loongson.cn, zhengqi.arch@bytedance.com, baohua@kernel.org, anshuman.khandual@arm.com, willy@infradead.org, ioworker0@gmail.com, yang@os.amperecomputing.com, baolin.wang@linux.alibaba.com, ziy@nvidia.com, hughd@google.com References: <20250507060256.78278-1-dev.jain@arm.com> <3fe90c96-da4d-4240-bd58-0bed5fe7cf5f@lucifer.local> Content-Language: en-US From: Dev Jain In-Reply-To: <3fe90c96-da4d-4240-bd58-0bed5fe7cf5f@lucifer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 57759180010 X-Stat-Signature: 7gu9t5pezhqb6jtnuh3e74xu6hr1mbg1 X-Rspam-User: X-HE-Tag: 1746768436-673049 X-HE-Meta: U2FsdGVkX1+pmfPU0aRFAu8vC7d3qmw+1xitjNx2J4QllrGnm0I8hDoraIssg3pNdupKPwon611ueMifgPCf4+1l56LZKyoG7AVv/NSI/JKcKDrAMvAXUlXwQ+pdZp81IHchlByClFx5jemu7k7FdelZjkg4zaQ5Wa0P7ZTIgh8sPV2oWC6m0MHcjsPwqUI1dteoBO+9y2REeNasDLAqxsqgSmOwUdxRd7kGLDuxob9onzadGM+jZ4UlsT7kRcM6N4nSo5+O/7ilBYNYIkAR7WIHGFH+DUmPBOoEITJWESIsbjVCxPZN7QzCnzA/F2Uw2U48YUOC5hCIIqJmnmpaznM2bBZHvvEJgZojyjbZAYex+kOIO4Lw47zSUAXCOJh7MoahJKyMb97Y2eXyahIjcm+1H3PswLVHtgZv9aTdyXPOz9NLgn3gjiuZ702mead1RHA97pSPWKzQcH+Co/RJa+V9+H1pulQnqTXshV01GZl34ObaEtRPJwB5su4Gw8NsUq5BIIe59FErBexrzdlDf79LWowHRoWfkF40OphCrXhtfBx8pSQSAEKCX4c7DWAn9IXbDyblFfb+nljoMJM8behH+IVMbiPOIqyd3ew3+nbQjv0WPcVOUYB+LDJAC+RQB7Bw+9a8alwTmOMZjv8TRuIIAYzXYtVisv85DRQC9C7w/O82Igi+0kyT46F7vHCfBwr7MzcBehcp/ouaqVmvRwLgkr/LYbPPBwuwlbDFudYfK6wYf21cD43jVDdg6JpQTjngeaV0cC/6qmUEDv7v3bdDUcblCQvk8EfLjOvS041w55s3ys37aIqzE/CnfPphX0FFjp4RAgYUcuUuG4AQvHfD+75G5yDFckbDi/7N8UOqe7B+Y243qJVN12bZQYApm8if84hrtbrigy1p6X9hLo+cos9Z8IBmFDh3e90AYUJfpjZttCpW+fVv5lmLAkQiaG3CNuzKX9o82m+L9mR Y+WfIpUu kc/YK5fK+AlpU526a5xbxwaLwgOuAVYWsoxqLNQbr3bPt3IwWianlfj12947nhD5c752jNNHJwDonK6tmyAmDwPG6GSCrE/kvnMNZm9pfQTrQ/GkUg0bD0YNuQRHm2wQURBzen4z5OoBvRXHjBigiOVa5bg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 09/05/25 12:05 am, Lorenzo Stoakes wrote: > Dev - a general comment here - but let's slow things down a little please > :) > > The mprotect() version of this is still outstanding fixes and likely will > need quite a bit of checking before we can ensure it's stabilised. > > And now we have this mremap() series as well which also has had quite a few > quite significant issues that have needed addressing. > > So can we try to focus on one at a time, and really try to nail down the > series before moving on to the next? > > We also have outstanding review on the v1, which has now been split, which > does happen sometimes but perhaps suggests that it'd work better if you > waited a couple days or such to ensure things are settled before sending a > new version when there's quite a bit of feedback? Sure, I should have waited my bad, I usually do, this time I was in a haste with both series for no reason :( thanks for your detailed replies btw! > > This isn't a criticism really, sorry I don't mean to sound negative or such > - but this is more a process thing so we reviewers can keep up with things, > keep things rolling, and ensure you get your changes merged asap :) > > Thanks, Lorenzo > > On Wed, May 07, 2025 at 11:32:54AM +0530, Dev Jain wrote: >> Currently move_ptes() iterates through ptes one by one. If the underlying >> folio mapped by the ptes is large, we can process those ptes in a batch >> using folio_pte_batch(), thus clearing and setting the PTEs in one go. >> For arm64 specifically, this results in a 16x reduction in the number of >> ptep_get() calls (since on a contig block, ptep_get() on arm64 will iterate >> through all 16 entries to collect a/d bits), and we also elide extra TLBIs >> through get_and_clear_full_ptes, replacing ptep_get_and_clear. >> >> Mapping 512K of memory, memsetting it, remapping it to src + 512K, and >> munmapping it 10,000 times, the average execution time reduces from 1.9 to >> 1.2 seconds, giving a 37% performance optimization, on Apple M3 (arm64). >> >> Test program for reference: >> >> #define _GNU_SOURCE >> #include >> #include >> #include >> #include >> #include >> #include >> >> #define SIZE (1UL << 20) // 512 KB >> >> int main(void) { >> void *new_addr, *addr; >> >> for (int i = 0; i < 10000; ++i) { >> addr = mmap((void *)(1UL << 30), SIZE, PROT_READ | PROT_WRITE, >> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); >> if (addr == MAP_FAILED) { >> perror("mmap"); >> return 1; >> } >> memset(addr, 0xAA, SIZE); >> >> new_addr = mremap(addr, SIZE, SIZE, MREMAP_MAYMOVE | MREMAP_FIXED, addr + SIZE); >> if (new_addr != (addr + SIZE)) { >> perror("mremap"); >> return 1; >> } >> munmap(new_addr, SIZE); >> } >> >> } >> >> v1->v2: >> - Expand patch descriptions, move pte declarations to a new line, >> reduce indentation in patch 2 by introducing mremap_folio_pte_batch(), >> fix loop iteration (Lorenzo) >> - Merge patch 2 and 3 (Anshuman, Lorenzo) >> - Fix maybe_contiguous_pte_pfns (Willy) >> >> Dev Jain (2): >> mm: Call pointers to ptes as ptep >> mm: Optimize mremap() by PTE batching >> >> include/linux/pgtable.h | 29 ++++++++++++++++++++++ >> mm/mremap.c | 54 +++++++++++++++++++++++++++++------------ >> 2 files changed, 68 insertions(+), 15 deletions(-) >> >> -- >> 2.30.2 >>