From patchwork Wed Apr 9 09:38:58 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 14044374 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 F0AF1C36002 for ; Wed, 9 Apr 2025 09:39:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5767828003B; Wed, 9 Apr 2025 05:39:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FD326B0169; Wed, 9 Apr 2025 05:39:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39CAE28003B; Wed, 9 Apr 2025 05:39:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 197976B0168 for ; Wed, 9 Apr 2025 05:39:19 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B20971C78D9 for ; Wed, 9 Apr 2025 09:39:19 +0000 (UTC) X-FDA: 83314007238.06.869AD2E Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by imf17.hostedemail.com (Postfix) with ESMTP id 84D1F40006 for ; Wed, 9 Apr 2025 09:39:16 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=cRle58JH; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf17.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.100 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744191557; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=qXgmXI91rfrc093sRbBRSsEyn4YoZ8rNV1XRh41K/Yc=; b=MEMg1vBUxJFhdFjMspb8leTABrXfm0DZoFwVcfmKItbxArund08EQKUCrA2ex10UdNMzOn 9dv2/wsFvyo/jQfd2DvglED7u6QATN5NZJhGghGYVmNtdx8O/ND6M8VVn0GV1QlwTnnKiT xoKMYylhLOF34ewr0vB8SPr/4XALNPs= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=cRle58JH; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf17.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.100 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744191557; a=rsa-sha256; cv=none; b=mE8pnjB+8BwmUFzoJj5jW859qiFoxVYn+bC2Mgv+T40LIS5iYnNOQ4zOYC0WyjSVZPKdWy fbZr5a9wPfCbNPjL2TGyKciRdYSAR2+ONJHwBKZT/wl773FhTGdmLjLhOtEEoPmIGZ34+w pB5ehIJB/x1rxxtZVPgRG6ywAs6hvtg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744191552; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=qXgmXI91rfrc093sRbBRSsEyn4YoZ8rNV1XRh41K/Yc=; b=cRle58JH3btf+IT6IJwdyHUomOETWq6RcPvChrLD76G3cKY7xTuVDiOpIlrFQZXSwcBJLQ1jmETwSjf0m7YIA0nYg/w1Z6UXbtbvAUVNmXqeF2a9skjQPy7aZPJBKlkqmwiH1aSYFdaHE0XwAUfmFwvOqDxllolf5FCBrMOiTf8= Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WWJihu5_1744191551 cluster:ay36) by smtp.aliyun-inc.com; Wed, 09 Apr 2025 17:39:11 +0800 From: Baolin Wang To: akpm@linux-foundation.org Cc: willy@infradead.org, david@redhat.com, hannes@cmpxchg.org, 21cnbao@gmail.com, ryan.roberts@arm.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm: huge_memory: add folio_mark_accessed() when zapping file THP Date: Wed, 9 Apr 2025 17:38:58 +0800 Message-ID: X-Mailer: git-send-email 2.43.5 MIME-Version: 1.0 X-Rspamd-Server: rspam01 X-Stat-Signature: 543g63hkyqoeo8ziofc96df1muaouqsq X-Rspam-User: X-Rspamd-Queue-Id: 84D1F40006 X-HE-Tag: 1744191556-78627 X-HE-Meta: U2FsdGVkX19cOdxQU6o4ZtJqyu23BKDslbqGMM3n8osqRbenXtVYoE6jWbZCvTcbVMLw9Lsf++YTBZhRRi1CWe3OQC4rIHUrETbQs8AzRnKLd4s4JrQuFxYplPDnLg0+/WaevsKhpTiRg+6UOYjW0KJE1495vGz/k+oSso/UZ3xfBm+Yj08EodRvA6cZQBlmYku1DmVmAP9bGPXzcU5VFPthX0yFGmew2szqRd9UqH0bTxYFkvqbIzRk8Q2N6G+Mg8MA3EfWBFAxkRHkYQ67YKOosiV/f3fLpicfPQQFhnOw5Zgof1hWC/EASpfQtIQQTNYRkiAUTESEbbDINa2l1oU1is722tEDfKwD3ZC55yY01ntFJJn8QzweL8KubEktQGiG3vwzA8qLWhybN2XO87XV+JpabZvUxallZPBf6CVvi9zCdaOQpYivAoneM4FEC2VxVzGcDaL3gOqgypl2vEkpikgEIv5/uw7w4g4iGO1jJPe/zkZE5ka3/XKli6MWSRsEUZuCbthvOfI7PrrIQc8dYs/sWGb9JKdjslUNNEsmnJ7TBPTbeQF5JBroZomBBYInYDZarFl9HdVDzGrqScmawMZ/QOnLAt+mzaxkprZv4hwlEdc576aDcgaaWy45hJ3kzqNgZhZKePLJmyHyezdi2JK+YqP0Q3pePWOvxQAu3FD0l8a6b9RfE4psa2Qbo+pMp8yKcuXPwTH+wk/1BOAIhT2pq7NTvxeb/ws7RyL1eD7kaktAo8wWoJ1KS+4wvqMQPXg3JVTj3b4XY1o3YLdCRlQGQx0jshPxw0OH2Cac4HdPXzB6/vQ2UZ4os1nNMYcpzZon4zFjj7pBQAZnY+Y73gCx4H+2grg860zqdtLM7IIA3us7qw41HN35fEf/bmdG+U0uf9/dyDil4R5d2oGLaZoGHaUES6NkFpcz59APSPZO2Z6nZxyO4YnZVj1du5isqEOzbpPT6rb8fMG y0hpKSNW i5sypINqpXej4A9sKgIYBOVgZ86VHp79tJUXZVJdXeeGLxjQxzyZsbPC8XlDRSu0lEMh0u5VmvzSlnySkuVUINMIAHGmToSd2jA7hpJ6CofCwqNI4NcJZXz1DOasC4Lou/ZLK8zGmLLBeVtB/vSASoAOiOuldY4S0jrFZroGi/58ORpob8cJ6giAqTpwirOypqvvxef2Sgp2A7LsWW/yoXk4kB5V5jKt40i9bSkC++LYSfT7jhy7nTJNrkdfIi2fGW/FzpgYUVGSgsEtxWKCtkZIGRuuqMazQ/W5CvpKqbLHQlkO1QF+WN00WGY1m0FWAcLdhHsnU++15n2cBQ/h1p/VNasIdRlq3t+UU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: When investigating performance issues during file folio unmap, I noticed some behavioral differences in handling non-PMD-sized folios and PMD-sized folios. For non-PMD-sized file folios, it will call folio_mark_accessed() to mark the folio as having seen activity, but this is not done for PMD-sized folios. This might not cause obvious issues, but a potential problem could be that, it might lead to reclaim hot file folios under memory pressure, as quoted from Johannes: " Sometimes file contents are only accessed through relatively short-lived mappings. But they can nevertheless be accessed a lot and be hot. It's important to not lose that information on unmap, and end up kicking out a frequently used cache page. " Therefore, we should also add folio_mark_accessed() for PMD-sized file folios when unmapping. Signed-off-by: Baolin Wang Acked-by: Johannes Weiner Acked-by: Zi Yan Acked-by: David Hildenbrand Reviewed-by: Oscar Salvador --- Changes from RFC: - Update the commit message, per Johannes. - Collect Acked tags from Johannes and Zi. Thanks. --- mm/huge_memory.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 2a47682d1ab7..955781b4e946 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2260,6 +2260,10 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, zap_deposited_table(tlb->mm, pmd); add_mm_counter(tlb->mm, mm_counter_file(folio), -HPAGE_PMD_NR); + + if (flush_needed && pmd_young(orig_pmd) && + likely(vma_has_recency(vma))) + folio_mark_accessed(folio); } spin_unlock(ptl);