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 39CBBC3601E for ; Fri, 11 Apr 2025 01:07:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA07A280148; Thu, 10 Apr 2025 21:07:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4D99280138; Thu, 10 Apr 2025 21:07:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3CED280148; Thu, 10 Apr 2025 21:07:23 -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 82820280138 for ; Thu, 10 Apr 2025 21:07:23 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 48E9ABBADE for ; Fri, 11 Apr 2025 01:07:24 +0000 (UTC) X-FDA: 83319974808.16.FE3197A Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) by imf11.hostedemail.com (Postfix) with ESMTP id 77F1540004 for ; Fri, 11 Apr 2025 01:07:21 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=h3mwORr1; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf11.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=1744333642; 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=gCQ6DzKnoO5vutwMKPVD3BAHxk5xZqVJHVeRC29A/NI=; b=XKbdb9jtfkilj57o79ZugcvpPRzVrUernPv26paiKMQk6VqG0z+0tlwTfB0rntG/cKKEsr Jr5eu0hjpJIIF9wj6oaMyqlbd+hbOPQ52jk97+xubHOO/0in8R2FhVCMBOFmqQq8fTAZmK dzI65xUIP1Bl+A1w+Bvp69NAi7MaS/E= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=h3mwORr1; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf11.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=1744333642; a=rsa-sha256; cv=none; b=uoHHYOli4Knba27O5wbQtM4JLCaQw9OqJRXJeYjIdIvjZxOf1mBZLUmlm350VXyCwmQMc9 a6q+CclDxNE0E23Nt+iX7xImHRUNrPLjy4aZ1632psFT4/LXU+m/czea7Kixm9Z/0sX9fH FDuzoX/Iy6TiKkRcfZS9VUMlD07KFQk= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744333638; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=gCQ6DzKnoO5vutwMKPVD3BAHxk5xZqVJHVeRC29A/NI=; b=h3mwORr1sbCtR+w7PByh5yQR/LstoGt0t2RxefUcx51W+NMq2jJaf6GQEhXHL9AGe8exUNo6pFCAlr3MKN9XZWPHJRCoJPF435JWsEdZDAvTWRSdQJTHtHLIdXVfl3ZsgByfSt6ORoMPt5x1DMbOrEbVWxo8jmDYgkKMHuzu1Gs= Received: from 30.74.144.105(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WWQqSYz_1744333636 cluster:ay36) by smtp.aliyun-inc.com; Fri, 11 Apr 2025 09:07:17 +0800 Message-ID: <23fdc11d-e983-4627-89a8-79e9ecf9a45a@linux.alibaba.com> Date: Fri, 11 Apr 2025 09:07:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: huge_memory: add folio_mark_accessed() when zapping file THP To: Oscar Salvador Cc: akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, hannes@cmpxchg.org, 21cnbao@gmail.com, ryan.roberts@arm.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Stat-Signature: y8hasac8w5yg5fy5zbwpf4kmbjz44fww X-Rspam-User: X-Rspamd-Queue-Id: 77F1540004 X-HE-Tag: 1744333641-737857 X-HE-Meta: U2FsdGVkX1+USosoIcsDA80N5/4WQIJKejuRABaz5Xc/blk7My8nR3JRiMyq5TNgAwo03Xk0fxEXJBBQllqNEvANE7YCvDEckZnV2tPpXIWvR6OHas9HQujEVfbA13Sc2JaDxANL6L9eu69UgsbTsb8YCwSzVLSbG1fwkDgscxErq10nzG+FXpBZ/3E+X215ClUpyD6m50LjXB9/7tD6RYNY9Ty1hLi9PI5BMDwrWc2DVyAy4E74RDy9/BlO8V4K9hMlpNN7V7+W+HKnz0NkjgQ6QLFU60QZnmjXWK5E/nltn0xhyB4kPaCfnx2I/JbjGrEhDwll6Lafs55QDL3DpbVOhUbh62AUsjtexESI+54fai8mvZSRWuRMFg26ZLpgyLjw/Fi7Q/LancrlIa7SShXf5yNTHLZz0DKzYqOjAktkYn/ae0FgV2tU3mrMpcwaD/fdcOjOy38ZJriagrHcPdQ/UzBLTVnC5hPATnabj38Gj4kIg/sP+XQwvp8FkjhXm9bUe2LTr5cgvPon8o3NbV5EJ7Qz80eadouutDaabUSrOjeoXrQs7Y5kqdQaCrwqkt4YLkrcX4axaN6IDPx7UXjY0FbJUaIjC1UDkEoyKgn1CmQq5BjUP5iRWVQSgMsbaNQCR7BKFpMyAFdX+JhlKvcSHDxPuVB0+1haSSCriO/Emch8RGA0Kdfs7abKgqsPsoH2/nLWE/JKbyVhWgQF6L5vOUJ2O6n1h0pYg2s6K+Eovsm1IU9oG2JTinMNRLH5XGIjZSbtwEnJA3QM9Rr5XlHB2l2rYZwQ1e+q2Cj+Kvhq4dwQwr2Bdw9ov/bsUyu/6ysY+TnpJtGH5C84lRiadhxF8UOV/JoT4TN/ckRHVRrBWURYcdvav6Y2Doy5eV1J0ZrTvBbLHzBxfWVDqPnbP4EK/YTwhs1nIC2B068E3WoWmGlHpnrdXUFvKirSqYJeDWlXHaR04JvWducYyC+ ZFb9HvCM a5ZOYx8JnPpiuJEMy1u2IfEaLcKQOvSCZva012sFiSzJUpf6UPjxldNDeCMAohsaIeYB07YiJgwI3OSKYxvXZZ8qfXljVkDs0SfLOw23tL0oUwGSHEned9631v9dwIWVIxf3XrbpVl2Tj+Gav5WY9z9imxOlTsYg/SyT663prVIkAOjKCw87MbUaukzLNfGDT06aoYrLsLrfW2VyyCTsPJxQsvq5BZd8LVgoI0U+SnJJCjsZuJVH+UES32OnFcsO+rzgebkluyi1H7/Z7gjCBySAxg74I01BgZcefVrBnKexANjfTEZSD63Wtm4L1q2sr0eshG8FlGrxQtFF2EE115Jtr+YI/8Z+EiClcF4NrVO1e+0ugMiLWoESSDbp+JIwPLPbsLxKlA1rT9V6kY/gklKxR8w== 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:45, Oscar Salvador wrote: > On Wed, Apr 09, 2025 at 05:38:58PM +0800, 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 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 > > Reviewed-by: Oscar Salvador Thanks. > Although I agree with David here that pmd_present would be more obvious than > flush_needed. > It was not obvious to be at first glance. How about adding some comments to make it clear? diff --git a/mm/huge_memory.c b/mm/huge_memory.c index b3ade7ac5bbf..93abd1fcc4fb 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2263,6 +2263,10 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma, add_mm_counter(tlb->mm, mm_counter_file(folio), -HPAGE_PMD_NR); + /* + * Use flush_needed to indicate whether the PMD entry is present, + * instead of checking pmd_present() again. + */ if (flush_needed && pmd_young(orig_pmd) && likely(vma_has_recency(vma))) folio_mark_accessed(folio);