From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1679128640C for ; Tue, 10 Mar 2026 08:02:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773129760; cv=none; b=pEP+iYZnXFiyeYN4OllAkj+y9fcdbabfaNm5Apa8MCFsyPHu0VT5p54WcH92csiGR0kSnzg5ssnUjIp33Qvaavx7k97Tsfl13kYVqFREHKlKnye4uX7D7ONFntt9hz7OvvcWK0iP+tgoguUll0g/W3eDhrIcmNZYA4bZVQJXyuA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773129760; c=relaxed/simple; bh=V8I3M0Bv0LCRbTF4LHTnw2/E8YY1O6TGUgahodOTqrc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qFV5A18x2lMBeKQgsdwc4xcWCTxno3apYTJCcCQ/BslcTVrAFLkQG/kmnrqwsf+QZCLdHayfG4+lHyyRaWnb7ygqD/xfIqtT927Rsa+mOR2z2trKk2ZRXfG9cpn6DdiT/L7ylRJxPcEqtws7fwG8yfgD8jpGKa4qmScBtSS6r6A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s7BxM9IC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s7BxM9IC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D0ECC19423; Tue, 10 Mar 2026 08:02:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773129759; bh=V8I3M0Bv0LCRbTF4LHTnw2/E8YY1O6TGUgahodOTqrc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=s7BxM9ICbUPacTle/92NHI3PD4PjiQ+NU8F6hb2iW+4J7NYe3dxHe2D7P2ZmWxOB+ WvtYUYyDYSLjkd3MkbRmHN5QAVZ+fe4ylTx+L41r3GIcEGVyYwOy9MbyNST+sK0tZK 3lQiLdreSlLIu9GFhd3u5De6XHVcpD2qFep3wOqFjXkhPXVnWoRYADJ4og1nZR4BL+ Qszp5jy7lvYL7Yu8RCnE1yPl6NJbiDGcns/T8LqtGpmB5iGwiCQ4As6hWbpDt3u+1H Xj1wCTTqUnLDhIfFIUxPIOPhNnG8EvoyriYXEfsyojgU21Qwn2Hg1c/AeOZFwKIVvF Jv4/o6tGYDUbw== Date: Tue, 10 Mar 2026 08:02:29 +0000 From: "Lorenzo Stoakes (Oracle)" To: Dev Jain Cc: akpm@linux-foundation.org, axelrasmussen@google.com, yuanchu@google.com, david@kernel.org, hughd@google.com, chrisl@kernel.org, kasong@tencent.com, weixugc@google.com, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, riel@surriel.com, harry.yoo@oracle.com, jannh@google.com, pfalcato@suse.de, baolin.wang@linux.alibaba.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, baohua@kernel.org, youngjun.park@lge.com, ziy@nvidia.com, kas@kernel.org, willy@infradead.org, yuzhao@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com Subject: Re: [PATCH 0/9] mm/rmap: Optimize anonymous large folio unmapping Message-ID: <032ab9a6-a49f-41c7-81fe-1c6fbaf94a79@lucifer.local> References: <20260310073013.4069309-1-dev.jain@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260310073013.4069309-1-dev.jain@arm.com> On Tue, Mar 10, 2026 at 01:00:04PM +0530, Dev Jain wrote: > Speed up unmapping of anonymous large folios by clearing the ptes, and > setting swap ptes, in one go. > > The following benchmark (stolen from Barry at [1]) is used to measure the > time taken to swapout 256M worth of memory backed by 64K large folios: > > #define _GNU_SOURCE > #include > #include > #include > #include > #include > #include > #include > > #define SIZE_MB 256 > #define SIZE_BYTES (SIZE_MB * 1024 * 1024) > > int main() { > void *addr = mmap(NULL, SIZE_BYTES, PROT_READ | PROT_WRITE, > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > if (addr == MAP_FAILED) { > perror("mmap failed"); > return 1; > } > > memset(addr, 0, SIZE_BYTES); > > struct timespec start, end; > clock_gettime(CLOCK_MONOTONIC, &start); > > if (madvise(addr, SIZE_BYTES, MADV_PAGEOUT) != 0) { > perror("madvise(MADV_PAGEOUT) failed"); > munmap(addr, SIZE_BYTES); > return 1; > } > > clock_gettime(CLOCK_MONOTONIC, &end); > > long duration_ns = (end.tv_sec - start.tv_sec) * 1e9 + > (end.tv_nsec - start.tv_nsec); > printf("madvise(MADV_PAGEOUT) took %ld ns (%.3f ms)\n", > duration_ns, duration_ns / 1e6); > > munmap(addr, SIZE_BYTES); > return 0; > } > > On arm64, only showing one of the middle values in the distribution: > This doesn't seem very statistically valid. How about you give median, stddev etc.? Variance matters too. > without patch: > madvise(MADV_PAGEOUT) took 52192959 ns (52.193 ms) > > with patch: > madvise(MADV_PAGEOUT) took 26676625 ns (26.677 ms) You have a habit of only giving data on arm64, and not mentioning whether you've tested on any other arch/setup. I've commented on this before so I'm a bit disappointed you've done the exact same thing here again. Especially since you've previously introduced regressions this way. Please can you test this on (hardware!) x86-64 _at least_ as well and confirm you aren't regressing anything for 4K pages? > > > [1] https://lore.kernel.org/all/20250513084620.58231-1-21cnbao@gmail.com/ > > --- > Based on mm-unstable bb420884e9e0. mm-selftests pass. > > Dev Jain (9): > mm/rmap: make nr_pages signed in try_to_unmap_one > mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one > mm/rmap: refactor lazyfree unmap commit path to > commit_ttu_lazyfree_folio() > mm/memory: Batch set uffd-wp markers during zapping > mm/rmap: batch unmap folios belonging to uffd-wp VMAs > mm/swapfile: Make folio_dup_swap batchable > mm/swapfile: Make folio_put_swap batchable > mm/rmap: introduce folio_try_share_anon_rmap_ptes > mm/rmap: enable batch unmapping of anonymous folios > > include/linux/mm_inline.h | 37 +++-- > include/linux/page-flags.h | 11 ++ > include/linux/rmap.h | 38 ++++- > mm/internal.h | 26 ++++ > mm/memory.c | 26 +--- > mm/mprotect.c | 17 --- > mm/rmap.c | 274 ++++++++++++++++++++++++------------- > mm/shmem.c | 8 +- > mm/swap.h | 10 +- > mm/swapfile.c | 25 ++-- > 10 files changed, 298 insertions(+), 174 deletions(-) > > -- > 2.34.1 >