From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90F6E23EA86 for ; Tue, 6 Jan 2026 13:22:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767705729; cv=none; b=jrigvaS9aJYOLCEe+QfBHpBrR44elCUjU3bki0VjBK6nWd5E0WXd4OoynuQRHK83R2EfAX5bDkFStNkf8ssqnhviWnb7iH4+vFn7Cly1I8mOCHy3wMQcZCKO9dfFhBDhidAKefcxtJwlX/NHntNJLM+tMw43d5fxuH1Cz6nkWOA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767705729; c=relaxed/simple; bh=pgJ/7z/EmQ7rKbqj8aDUN2o1FZLFX9L0L8PrG3xRw4s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X1UCdKyOQw1wyA4lAFl3yks12xJUNN5J3b08+rXUOGsP92mqbz0yh5Q8hcZpTu4UFcKKeRpjMXzTRRY9mRs/dYvArz1XxNg1XwBvBad+e5MkvPj1CCYOnfYPf1A28kuhs0j4I7GZ/c30OU9Ri1oTHukNf8hmlOlWr+/nmuPYwUY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=G7l252kZ; arc=none smtp.client-ip=209.85.208.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="G7l252kZ" Received: by mail-ed1-f67.google.com with SMTP id 4fb4d7f45d1cf-64baaa754c6so1258572a12.3 for ; Tue, 06 Jan 2026 05:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767705726; x=1768310526; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=AnaTrYgO4HShbHNfxp0Gz+GzpJfxlGJKnBUzxWHLg+w=; b=G7l252kZGN3Xf1Nhj0TC2gCZ3TB7NIEUhKRKMLUI6t+RkNBcMmwcWJ5fxDsOUWxeav lL3OVXop9QbuCHqMxi1mKHVcQyZxrguwKZrk+YHo/Uar7EaL4R52qEXu/AgO+IoOh0xZ EgZlQWBmfNhq6UiEpBTlORNwZKlT3yTmizL0RacmWMPuvy0EQ66BDu7GUWKJn/AmLx3M kIIoM2bC3dpa8sYUOq25/SH/1bWDFtCkQILRaZhM+DiEMosWE9KzNZC5KMfKEAHVoOFX xIja8xE45guJnt5yvkEM6/uoV0r3WyVxLki7E6IE6ljH13tvaNFy4CTDIn33mSpvc+SK tcVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767705726; x=1768310526; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AnaTrYgO4HShbHNfxp0Gz+GzpJfxlGJKnBUzxWHLg+w=; b=WeCdtkd868TzORtfWCiXGnxWifqA6Sv4U6sexTcFTbnrYJX5SSBVRHGh8WvkdKpYAU RlgbwtYnsiuWmKjgspMhNt6+7M+oak0yq6SmjUBZXyGaCWfNkalsp0vO2PkmamClaz/1 3oid6a2FDCfnFRvq7IKkgCg2FT7pLIgbeu8QRvB3vgm7hgFWkX3VNZWHWEfPegUj8CzW /+et+gJWSI55l1iQhovk9ndQ/EwOpRXPQVSm6UUso1ebvSfFTfiIRmRNLWMMLuVzvnlU UyuWU4UdZk/EN6hdjCpC18M6AwfTSQxJ+yKJ1lBoW9U0jdp/3Pbs6xsTWwyc9s94B0dy Z1Ww== X-Forwarded-Encrypted: i=1; AJvYcCXgwkFGO6Fj8ZCyGUD8bwS8N2BtxKqBgFzcKp2jpiSmVpXE5cl5D0qH0rxQ8y/uH/ml5+knGvpBu6kUuMQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1CcQwTZNykjJWHUC3udfw6k/MLI02DS0L55yNvz2h243bh1C6 jeiejGsXEwfsuzeA2xS7x5Z25aGvandNPc9khzsrGcwIJzgM0M1gqAgG X-Gm-Gg: AY/fxX4PbS4Wb9oGFuzHrv9QyUWXhpBN18jGAaWvBph5Eqdh+M6C8NO4da2hrZ/ccxG 2F1GqmtmGNr2Ac9NA9JLZAm5jVX5NnPjxaUoDK4Sotd9yRRIx5oanhrFw8dANjMeHWmABMj9IFr x+aVHWcJ+RxONEPcMBatMvkIkpJ2IEAB4faxTt8kolhmGxoXqc6REU1hAZtbCa44db2DZo7N+kY c9QyN4JHCA/eL0ixHscH2VSx+2w1+cR+Xis798LXB09aYag52+X4XRmT7IEcw2CCLMnmjo4BJ6X Yo3CypQdkR9pr9QQHMTKd5g3soAY/vUp1GoAA/x/R73LKS+IJ6nThovUaGNQMEfk3eJejkG+K7I ZvQAiyWhe6WISk/KvLn3tKeSdMH4Lx9Bpz+k6BpJMC2fQDJi6Rw8NFY341CoaTeHmOrayBO6b81 J/atkj6D6p3A== X-Google-Smtp-Source: AGHT+IGOQUwp29CuBStqL9lweYRQ0EBUwNwC7bXQ4+jGDqmOepHg0UTslUPPgNQcAc0Gl4FJ2lkzvg== X-Received: by 2002:a17:907:7242:b0:b7a:1bdd:3311 with SMTP id a640c23a62f3a-b8426c4a81cmr316783366b.62.1767705724583; Tue, 06 Jan 2026 05:22:04 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b842a2cffa4sm225646466b.30.2026.01.06.05.22.04 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 06 Jan 2026 05:22:04 -0800 (PST) Date: Tue, 6 Jan 2026 13:22:03 +0000 From: Wei Yang To: Baolin Wang Cc: akpm@linux-foundation.org, david@kernel.org, catalin.marinas@arm.com, will@kernel.org, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, riel@surriel.com, harry.yoo@oracle.com, jannh@google.com, willy@infradead.org, baohua@kernel.org, dev.jain@arm.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 5/5] mm: rmap: support batched unmapping for file large folios Message-ID: <20260106132203.kdxfvootlkxzex2l@master> Reply-To: Wei Yang References: <142919ac14d3cf70cba370808d85debe089df7b4.1766631066.git.baolin.wang@linux.alibaba.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: <142919ac14d3cf70cba370808d85debe089df7b4.1766631066.git.baolin.wang@linux.alibaba.com> User-Agent: NeoMutt/20170113 (1.7.2) On Fri, Dec 26, 2025 at 02:07:59PM +0800, Baolin Wang wrote: >Similar to folio_referenced_one(), we can apply batched unmapping for file >large folios to optimize the performance of file folios reclamation. > >Barry previously implemented batched unmapping for lazyfree anonymous large >folios[1] and did not further optimize anonymous large folios or file-backed >large folios at that stage. As for file-backed large folios, the batched >unmapping support is relatively straightforward, as we only need to clear >the consecutive (present) PTE entries for file-backed large folios. > >Performance testing: >Allocate 10G clean file-backed folios by mmap() in a memory cgroup, and try to >reclaim 8G file-backed folios via the memory.reclaim interface. I can observe >75% performance improvement on my Arm64 32-core server (and 50%+ improvement >on my X86 machine) with this patch. > >W/o patch: >real 0m1.018s >user 0m0.000s >sys 0m1.018s > >W/ patch: >real 0m0.249s >user 0m0.000s >sys 0m0.249s > >[1] https://lore.kernel.org/all/20250214093015.51024-4-21cnbao@gmail.com/T/#u >Reviewed-by: Ryan Roberts >Acked-by: Barry Song >Signed-off-by: Baolin Wang >--- > mm/rmap.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > >diff --git a/mm/rmap.c b/mm/rmap.c >index 985ab0b085ba..e1d16003c514 100644 >--- a/mm/rmap.c >+++ b/mm/rmap.c >@@ -1863,9 +1863,10 @@ static inline unsigned int folio_unmap_pte_batch(struct folio *folio, > end_addr = pmd_addr_end(addr, vma->vm_end); > max_nr = (end_addr - addr) >> PAGE_SHIFT; > >- /* We only support lazyfree batching for now ... */ >- if (!folio_test_anon(folio) || folio_test_swapbacked(folio)) >+ /* We only support lazyfree or file folios batching for now ... */ >+ if (folio_test_anon(folio) && folio_test_swapbacked(folio)) > return 1; >+ > if (pte_unused(pte)) > return 1; > >@@ -2231,7 +2232,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, > * > * See Documentation/mm/mmu_notifier.rst > */ >- dec_mm_counter(mm, mm_counter_file(folio)); >+ add_mm_counter(mm, mm_counter_file(folio), -nr_pages); > } > discard: > if (unlikely(folio_test_hugetlb(folio))) { >-- >2.47.3 > Hi, Baolin When reading your patch, I come up one small question. Current try_to_unmap_one() has following structure: try_to_unmap_one() while (page_vma_mapped_walk(&pvmw)) { nr_pages = folio_unmap_pte_batch() if (nr_pages = folio_nr_pages(folio)) goto walk_done; } I am thinking what if nr_pages > 1 but nr_pages != folio_nr_pages(). If my understanding is correct, page_vma_mapped_walk() would start from (pvmw->address + PAGE_SIZE) in next iteration, but we have already cleared to (pvmw->address + nr_pages * PAGE_SIZE), right? Not sure my understanding is correct, if so do we have some reason not to skip the cleared range? -- Wei Yang Help you, Help me