From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2FFCE3D3D07 for ; Wed, 19 Aug 2026 06:50:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787122241; cv=none; b=OkgJHOw6DNNtXlMuF8M+JoyMPpiw7O7I2iNJdFdENvBbgaN7aAm8mdDkghYjV4gyXeZkabMDwmIhvKPAISvUSO6OTgGRGLr5gt6o7VT3JCdKcRnG1+gQxQwjpNPAwM2mUTwoMUemhIGfEnkFtgApNJDbCOO/oL9qJIx3WuhpQGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787122241; c=relaxed/simple; bh=hzyGyhdGrUBLrpKdCTeSQJcY1CtIsQebRKlFpcJXqno=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SKzZy+DAMDLS0KA9LsrMDr+4mdlMTfWAz3vh4dd/iHARuYLKp2mRb8FzS5mfWAhFQX0FTxGDw41WL2XLyXRqFtlY9HwiFe2qU0IwYLTcl+EMnJRIafT7xSdpsU2DYh5rCYjwx1P74qe5x6NdSrv4JuekbGzU2JjoBv7bPraWPjU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=qd6JsvZR; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="qd6JsvZR" 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 DF72514BF; Tue, 18 Aug 2026 23:50:31 -0700 (PDT) Received: from [10.163.138.181] (unknown [10.163.138.181]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 201FF3F66F; Tue, 18 Aug 2026 23:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1787122235; bh=hzyGyhdGrUBLrpKdCTeSQJcY1CtIsQebRKlFpcJXqno=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qd6JsvZR1+bVNlqKjQsejmd57DcATLi+C5moZwtk0ZQv8bPuz2aLXiXQfeAwWX2h5 +kHySCsMVOUow5PJOaR9MCUfjK+hEB5fuyM+BT3YQIi9O2FzCv/JHhoytWiZOt397j l8NRF0u4evNo9er1Itl7gN+C3BIaQaVVWt6QxyrI= Message-ID: <80632d25-df40-475b-b7d0-912d657a977e@arm.com> Date: Wed, 19 Aug 2026 12:20:24 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/8] Optimize anonymous swapbacked large folio unmapping To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, hughd@google.com, chrisl@kernel.org, kasong@tencent.com Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, baolin.wang@linux.alibaba.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, baoquan.he@linux.dev, baohua@kernel.org, youngjun.park@lge.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260723070905.3422276-1-dev.jain@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: <20260723070905.3422276-1-dev.jain@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 23/07/26 12:38 pm, Dev Jain wrote: > Speed up unmapping of anonymous swapbacked large folios by clearing > the ptes, and setting swap ptes, in one go. > > The following benchmark (stolen from Barry) 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; > } > > Performance as measured on a Linux VM on Apple M3 (arm64): > > Vanilla - Mean: 37401913 ns, std dev: 12% > Patched - Mean: 17420282 ns, std dev: 11% > > resulting in more than 2x speedup. > > No regression observed on 4K folios. > > Performance as measured on bare metal x86: > > Vanilla - mean: 54986286 ns, std dev: 1.5% > Patched - mean: 51930795 ns, std dev: 3% > > I tried magnifying the difference on x86 by using 1M large folios, but > can't spot an obvious improvement (looks like my system is too fast to > benefit from batched atomic operations!), hinting that the benefit lies > mainly in the reduction of ptep_get() calls and the reduction of TLB > flushes during contpte-unfolding, on arm64. > > No regression is observed on 4K folios on x86 too. > > --- Hi Andrew, I am not sure what is the current process in mm regarding sending patches during merge window - would you prefer seeing v2 after merge window or shall I respin?