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 91A1EC369A4 for ; Thu, 10 Apr 2025 09:05:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 504FC6B0309; Thu, 10 Apr 2025 05:05:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B1566B030A; Thu, 10 Apr 2025 05:05:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C7AF6B030B; Thu, 10 Apr 2025 05:05:12 -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 1DD4C6B0309 for ; Thu, 10 Apr 2025 05:05:12 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 69C9280704 for ; Thu, 10 Apr 2025 09:05:13 +0000 (UTC) X-FDA: 83317550106.30.A7ABD03 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf06.hostedemail.com (Postfix) with ESMTP id 0EAFC180007 for ; Thu, 10 Apr 2025 09:05:09 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=ErghuLME; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf06.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 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=1744275911; 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:dkim-signature; bh=PFk+KrYiLK5TPKtYUz6wWoaE4cbubrT8jUHqRNUo/jE=; b=1e7Ia3t9Re5fPcVdvVAwzcXlFKq6L5mLaNJOWAXFX8nwTDyyLymrDXrrg4ZpElEXi4PoVP 9WJS/q+G96B0/ChGnjkgZpSMM5e/u5ThuuxBN5oT+51J8jWFa93VWvyaK652Hb880oNVtR 4Pih0ysG4U39ydu4qzRWIYxOF6r1HuA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=ErghuLME; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf06.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744275911; a=rsa-sha256; cv=none; b=irFWWkq7N8PByhyOjtarcZSOS/OEVRpUMX8vy+GdAY5UE5oABQWLFKpvXIG21BGsswnUd+ X+o93RX1kE22bk1EUoaUQMGzixqgN8NGNNi+M0RdH6b2bkShhbseVFs2O5FvF5P2yEDEBc WaY+388RU7GZKxlgowYtXwD9obQqJ9A= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744275907; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=PFk+KrYiLK5TPKtYUz6wWoaE4cbubrT8jUHqRNUo/jE=; b=ErghuLME8yqb7WFtdjecm03+6+6altMzpfWkJ+nbmxFjyu3QO87Wg7Y8KdnwQ8faVqKNhNFidIR4pT16iLH+mhaOXjrJA6bFkFH0kzvw3jeO9Tm83qbIbIWZkhwr0L22gN9CQAJ/Yi9xXWwDpYiVtkSePZuGnp7XDrzy1LQU1+s= Received: from 30.74.144.106(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WWOJ9H4_1744275905 cluster:ay36) by smtp.aliyun-inc.com; Thu, 10 Apr 2025 17:05:05 +0800 Message-ID: <5c52b67a-8e7e-4dd7-9127-96944715d883@linux.alibaba.com> Date: Thu, 10 Apr 2025 17:05:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm: huge_memory: add folio_mark_accessed() when zapping file THP To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, ryan.roberts@arm.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <34bab7a60930472377afbfeefe05b980d0512aa4.1744118089.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam01 X-Stat-Signature: efu4mhfajokoypet4rwgnubwp19b777c X-Rspam-User: X-Rspamd-Queue-Id: 0EAFC180007 X-HE-Tag: 1744275909-380707 X-HE-Meta: U2FsdGVkX1+JA2V7OQXQpT+SfNmpo9oxVDBWyS5x25VHDL+RNveXVqs+/SGxTk52yoAai5WVBDdL3e0aVDHDGdGT3Ewg016ZMb3vVwNbGaywRo0SPq385M1Ldc6w80+SD4HQAWPClyWZ8MrhMp7ko5r0LWwioWe+Q9Zz3aHKjuz5htNFI5OzgbnF+s5l+8ruTsOAso51niOB62Fa1wCyilMgjJ5sho0/0oWSQF1n19y6Wp94xMgkBy+NeqU4BAF4UUz5rqxgOaax6Hkh5IbQ09Wkd1PnZ+is2e1KUMGD3Z2iqAsMM8bJzU0hzlCCP6Jq+uxRjVFtY6MYG+0j1uTWrf9Lu6JXsAVZ6DfqAQ9nYZ/RLj45749V4dA3hHi//reswYUoU74gu+i+KvZRkcNUxYEDrwfDjcEFxY2zXwn4FJU5PYpoodFzcivx2BwtZmAQD8QITNDiV2vYOQIfIr6SjAXVhuZsah+tIjFoCMeuwwBSJNYxS1qfdB+HNhaQTlp/HAj4PZW0RnrEQdHlwhAO1valkxWg2ft2LIE6XzSeB41kGS1KlDqfmFIypC8EQsLYXecV8lHdQG7hK/RIxbCqjV8P37/zokRvIG0eQIEb8XK6uvC0OZqpGPgi+4G7ZtoDTFdk+G5sEflx+WaARCF/aqcRyRkr7flk4mkR8faGxoxKryXMQBnzOGm8DGWK22V5AtwqzQFxqydUgsHnhoyKv2738b7deJROdlhiZ5mfq660LRjhFPNPhVZpSOdKJfEWmwm89fGnh8inxMRaq1rvaD0dAjxIrsh/1fC/qMeBBwY2ilR9IZlDyrLJdi7YGC7bocaqGQ6u3+kUZnUxfrVcGm8VHlkqGH+FO3FEcko/rGC/mlUXC9nYL/hzrHkn8SV+beCB7zb7OIR4nJ/FQ8+1g14uA46dCu0XL0UalVNLJ9u0kxYDy9jYpt0LF5D01H2N4dGUVX/EIbWt9rHca6C Ii0mCQEQ 41+nl35/79TTVQ8adw6EYVKfpFyfjYJ/zfnPPdPg1sCiMevc62dlbiCSk0aS1TdstbIPqHzoJki2JOxmojWZ6ZH9f+BEtOr5esXADQ4vXZOhKcOqTjTX5BjNMY+xe66B1AFnE9XU3kS6a8yEaPNACy8P/Ap8sy2C4ilO7C7LSdDx4/y8lroCA/nl53BDg/Nk5dbDimMVIhSqn6lFh7KBzleDPI5kDDS3CDdl5ixptP5RFkYUEtgg1lQeMphTeXeexYHtNsLg/c4QtIRJ7oEH8YjJSsj/A8LaKpLLEMz2EZhj0nb6dRHrOqkuBSJKU0v1DWMbORhIB0/rtEOVieLk+okthUkPPxmjzhErDvFIJG7/idddyk0uzqa0jfg== 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 2025/4/10 16:14, Barry Song wrote: > On Wed, Apr 9, 2025 at 1:16 AM Baolin Wang > wrote: >> >> 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 more frequent refaults of PMD-sized file folios under memory >> pressure. Therefore, I am unsure whether the folio_mark_accessed() should be >> added for PMD-sized file folios? >> >> Signed-off-by: Baolin Wang >> --- >> mm/huge_memory.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 6ac6d468af0d..b3ade7ac5bbf 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -2262,6 +2262,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); > > Acked-by: Barry Song Thanks. > I also came across an interesting observation: on a memory-limited system, > demoting unmapped file folios in the LRU—specifically when their mapcount > drops from 1 to 0—can actually improve performance. These file folios are used only once? Can folio_set_dropbehind() be used to optimize it, which can avoid the LRU activity movement in folio_mark_accessed()? > If others have observed the same behavior, we might not need to mark them > as accessed in that scenario. > >> } >> >> spin_unlock(ptl); >> -- >> 2.43.5 >> > > Thanks > barry