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 73186C36010 for ; Wed, 9 Apr 2025 00:52:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EDD4280039; Tue, 8 Apr 2025 20:52:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69C48280037; Tue, 8 Apr 2025 20:52:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 564D3280039; Tue, 8 Apr 2025 20:52:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 396E1280037 for ; Tue, 8 Apr 2025 20:52:16 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DDE5B161795 for ; Wed, 9 Apr 2025 00:52:16 +0000 (UTC) X-FDA: 83312679072.23.F214AB9 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf21.hostedemail.com (Postfix) with ESMTP id 6F65B1C000C for ; Wed, 9 Apr 2025 00:52:13 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=mm0virZW; spf=pass (imf21.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744159934; 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=3u6V+RZKHcCI6WcdOem5D2yjNJ6f17csLnu4f6RrGNE=; b=fU+DDu8V+1VJMtLOk8iqsTqPz1sL9FNw25PTnZiG4Ejmjb72UGNL7AR5ejkUzY/FZw2Hav yr5cczJ1W6EqnAjwr+NU3QHArXznZ1oyeE0TKeoG2kzdiQcEfHttMFwUVNM51DCG/+sb/Y XI6RqPB9fZrBK4kHOvChD20tXNHzpec= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=mm0virZW; spf=pass (imf21.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744159934; a=rsa-sha256; cv=none; b=KC8h+nwlzYqAD375L0U2+MujDOJYaTpwAHeKlZ1jwriyt9zaOoO4Mqd5vPwgOsFoe1bc6k pvRDpNMPcvXLBmHWZPvwgQ1t9/196IAJaHl+VZlKAB5AD7qs+d6alZvFG6XVwrl2l9YfEo sfgSw+KMyU0UoP3xxfo2UiLP2hfdJ1Q= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744159930; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=3u6V+RZKHcCI6WcdOem5D2yjNJ6f17csLnu4f6RrGNE=; b=mm0virZWDGguvZx0rsN4fhb00cV/+wmcXkr5UcUBFsf1ftHc5PrEPGsdyIczEfpYSTqUg7xxA3tRbRSEx4v/Q+Q9dyhUI5QMASLE12NtFVE7NEcu0hVOGcDrXR/Mm1YWQP2njzLpG0fydeCRjMoclPTq2ydSUSpO2najAx5De78= Received: from 30.74.144.109(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WWHHqoY_1744159928 cluster:ay36) by smtp.aliyun-inc.com; Wed, 09 Apr 2025 08:52:09 +0800 Message-ID: <0b668098-5623-4062-b219-605dc91c0877@linux.alibaba.com> Date: Wed, 9 Apr 2025 08:52:08 +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: Zi Yan , Johannes Weiner Cc: akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, 21cnbao@gmail.com, ryan.roberts@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <34bab7a60930472377afbfeefe05b980d0512aa4.1744118089.git.baolin.wang@linux.alibaba.com> <282545E0-5B66-492D-B63F-838C6F066A22@nvidia.com> <20250408160205.GD816@cmpxchg.org> <2C391CDE-0C6D-4ECD-9EDF-5CC165999EA2@nvidia.com> From: Baolin Wang In-Reply-To: <2C391CDE-0C6D-4ECD-9EDF-5CC165999EA2@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 6F65B1C000C X-Stat-Signature: imk37wwxd5pxgsn8f3bzghutn1rs6dp9 X-HE-Tag: 1744159933-232370 X-HE-Meta: U2FsdGVkX18HkITluQikB+zB42pIv/rfBrPctyhcDoTXKap7YlU2zujC+/HBMqN0VX2H51h5PEOXxAqvHPA4PtFPfTnUZj6HCkO/v3xWefqW+HAS/xP0hVrq8Ezx45jD8IYnVjy0xAepqALbpZpNAub25a0XG9wFf5NRO9eaSjic8lqmw0WY+vpTSR97xup89JKzvkvjOwTg+wbgsJjobztIBrjCLPrVPmMy+B4WDFHfT5dlu2cM46puEPjO339SfFDN6PAeC6bWCmpS9tWEf7Qr/uyLLoPU7DHwRnkQfE57ymeo35g9kv5i4v/VeQ9LcrtcnzLgYQ4z8LINrUM1KlPyU6es4HzMhS19eeBKH6G9itA4vSA3lP8PH9rhVKRwA2wAa4f5W0rs8ty0EmtBsBtKJssAejWyEicxILP0jAvAH96+HtkzdDPrrwgQa9b2IWosDlzsKCezGPU/jJ9O6WY5u5/YXbL0oPH3oRbbu8kCE4uvSEDtG4KXCyk/fMt5UX/mc2P1Or5caP9m8EgJMS89znTZdaUx29Va+tUzUVaQhsSkU3xhxlbYRcIWtiJo7KL/nQp98hblFS6wDI0WFfBbwvcwwMJE5zj0/grlw9f4SkotGyXIocseKibNwydm3dtMeIVlP4TsYF1yfs3a5OeywdQ4m+TS0ESDmO7mSQWPQ0LtrLaerWGFzn6xNA4yxXkCtL/HL8SmQKo1tUpabWCWVbkXr3jYlQkR2kiLIu4J2vGApJ9nV00tsD5ykJcscS7ZvxebO+iMAxRxrs2SFXBn/BhWt/bEydDeD4I5E7DDsDWyMJqUN4TRNUVG2IghT/7Z/g3OZRMcRzWQOYEUXTXackOxxfa7PTLj9QdMAFoqSzmyQEsKqRx9YfxX4KGKup2CasT14u0EsQ1NiyVQimIrwUP4NHXTqQt6pk24P34DsahKgS07oetLOo5Y7sAZBV+rfOl1VpiiIcwksnI 9Y+QxoIt 59XdP9+ZOD1HPyaR2lyBJ4bkNzvUd32yp7CrcxAmDUM7n2j1eMvEGDLPf0oivyNn+cKpYk89AreEUONeZmPG59UNYdEQM76WHVX+1lBW+fZnsoPOcJYgRhlTScgZnKpPMD0gLnerCrrGvwFkYbGdTaVhlHKPb6AGdveJJhv1SN8ZX8vrPR5vL1OmOXeFz8gqt0qmbabT/Zc9sZEP9ZI9yS6Bc9xYhB1+esv56x+bZ/zd0ytU5fxp9xbvNBEBW/YFO36KXVggHfg+vgftWjkI5sM6hRaNQj5ogBDsVgIcodONhfTSsWMrii83VBs8mWnoPWDzYiFTudUfsBnedVYNQSvlgwPg7bGXjQmIPNocyyseCcJhCpLBwqchp2SrTQAzYiQVlFISmzna4uuy6bUU8TuLUCf2vN+Z+d23t2NjqwCJIJkE= 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/9 00:12, Zi Yan wrote: > On 8 Apr 2025, at 12:02, Johannes Weiner wrote: > >> On Tue, Apr 08, 2025 at 11:29:43AM -0400, Zi Yan wrote: >>> On 8 Apr 2025, at 9:16, 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 >> >> Acked-by: Johannes Weiner Thanks for taking a look. >>> How likely will the system get PMD-sized file folios when it is under >>> memory pressure? Johannes’ recent patch increases THP allocation successful >>> rate, maybe it was not happening before but will be after the patch? >> >> It's not so much about whether the refault can construct a THP again, >> but whether we should have evicted this data under pressure to begin >> with. It's more about IO and paging. And it's the same consideration >> why we transfer the young bit for base pages. > > Got it. It clarifies things a lot. > >> >> 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. Yes, that's what I also understand. Thanks for the explanation. > So folio_mark_accessed() will prevent the folio from going down in > the LRU lists, when PTE access information is transferred to the folio. > The addition of folio_mark_accessed() makes sense to me now. > > Baolin, can you include Johannes’s explanation in your commit log? Sure. Will do. > > Feel free to add Acked-by: Zi Yan Thanks for reviewing. >>>> added for PMD-sized file folios? >>> >>> Do you see any performance change after your patch? Not yet, just some theoretical analysis from code inspection. >>>> 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); >>>> } >>>> >>>> spin_unlock(ptl); >>>> -- >>>> 2.43.5 > > > Best Regards, > Yan, Zi