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 D10B4C3601E for ; Fri, 11 Apr 2025 01:20:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13442280149; Thu, 10 Apr 2025 21:20:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E2E8280138; Thu, 10 Apr 2025 21:20:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E77EC280149; Thu, 10 Apr 2025 21:20:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CB0D6280138 for ; Thu, 10 Apr 2025 21:20:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 493FF1217A6 for ; Fri, 11 Apr 2025 01:20:10 +0000 (UTC) X-FDA: 83320006980.07.73697E3 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) by imf06.hostedemail.com (Postfix) with ESMTP id 4F171180005 for ; Fri, 11 Apr 2025 01:20:06 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=HYy9qEmF; spf=pass (imf06.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 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=1744334408; 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=amhcLDqbTnuD6tlVLNEDxIaRocgED5CdIhUH1OvSHG0=; b=b39C5/07sCU7VYJuGegqhUJF4z72W6ueP2GokFCU8qGv5qcsFjkIdqboEw6WQz7OeTHh59 YKUKKAQA+HX+Ohv6S1lL895dFolFGvXRIziryN4wO4ZpMtqKG9p6I2QsPsm9kjxVF1p6bX btUMCybbNc2dAdYKFik0QOiGK18/ARI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744334408; a=rsa-sha256; cv=none; b=1lW7jUl8PUX6X8IWWWnHUH8LoAc6AjqztZAfEhTkXh5znIUxKch/SsD0Ij2hm8f+Xqqt0d rZa4KYe9ZvZQ88bogSJfNWSBLvat+dETgLNpxpZHi1P11RLvxSDmhZiAnJX0O+MAvhgRT/ 8S98mDJ0lrrtyO2Ty4Io/+8bZt0i+Mo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=HYy9qEmF; spf=pass (imf06.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.113 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1744334403; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=amhcLDqbTnuD6tlVLNEDxIaRocgED5CdIhUH1OvSHG0=; b=HYy9qEmFCBxIp4YUivkUrmFx0e/1fs8r2vV2EWhBxYlARbe7BK4HsT2NI545IF4JCNc5agoU+ntSArRxgsF4QRmbuIzOGi84uogMGmEoNAGSDQa26PSQl9TpZ3qb64KxSzTGzsfNCbe+H7ygTcRJBs1wlnkeyCqSCcK41qvbrCo= Received: from 30.74.144.105(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WWR2HW9_1744334402 cluster:ay36) by smtp.aliyun-inc.com; Fri, 11 Apr 2025 09:20:02 +0800 Message-ID: <247fca57-8280-41a6-85b0-03a32ea08210@linux.alibaba.com> Date: Fri, 11 Apr 2025 09:20:01 +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>, Zi Yan Cc: akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, ryan.roberts@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <34bab7a60930472377afbfeefe05b980d0512aa4.1744118089.git.baolin.wang@linux.alibaba.com> <5c52b67a-8e7e-4dd7-9127-96944715d883@linux.alibaba.com> <1E123113-7A0B-4D3A-AC7A-01767D7BF2D8@nvidia.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4F171180005 X-Stat-Signature: t7zys96fz7grk9bisnqnk9emdtwknmu7 X-HE-Tag: 1744334406-138337 X-HE-Meta: U2FsdGVkX18X0BD8k2P2e45Z7RwR9U6avzaYqq1bMn00UW4VrDVtV9Q5SkNHGxRS1cWw4Yv70BNVmUG6OqFbycyVdWoNXaXDIfZND1q7tj+mBO2s9nVP3j+RTjGpHHAac91TPRjN50QIwMZI59CHfK17C6N+4jGmVUf78H0K2aAKkFeyiK997AAhyGGGcxs1I2f4cKiqHt/tGLadvty3X+KE9boyhJGuKd+dtUmQKqNWlxnJBwnzWr7JLLgZn9Lml6+4ABHWZWFe40JYXhWdA64nJjGULy+LYStEPrtQR8n3JWikJ9xHNjQfQBDZMMOkHVnEBL6QapWmo7OnQdFgOAMN4GjLRxKZ+/qCnuarcgzW/Cj/FW1cL7iSrzVI+UkibIa8Y0vv145PUreKyvxJ+pYJvjdU8m4YmcFCy/KFThqwdDYqfysuj4QVSPzU63O3gEn9hgEUsFlxHZ36wHzsaGJKeX7d6UKk/wKs7K2XEvNDFXZjUQwlivgwRyVSz5SBN5anAZj3/Te939hpEJNy80oG/tyjib3WykxFORkW21aQneZ+bJjRgkilZ/n190Gndr8b1MNGWhJsT9XfjqBEBktzcQLQKNUlnj6Ito4ko+5j+3skW5cY1k8Qnzw/iiMULjgHru95YxJJN/CVfmITQoTUu11Elpzd6s0l6o/oPEaUjghmfTzrpcaR2NewIjDPOrQ7dBQpZ8shfTjI53a/4tkpa/aq2Y2nr0bSv5INx+2EkxatFUPLdBmmVocrZ6UjmLeBKodagAxHtcXXMuO0LiAv6fBrfRCdeUdXgtZpHrK+cCQz5IdeUHyNrbgHL19rL7XCma44ZRCnMlPDJixnr7Chc58lNtmoLHAUMrNVCr10M2XICUqgcVpUARz2yPr7imxYqRwRHGzUdO3g39Xx7olKbg9yI4YIlTCCYTkqy+le+bSuzdjkmttVE6f7OKPJx/43Oq7DX0WmLe8bOh/ 5vgLLeAz vLUJTDX9S4nlszLB0+hoSmLMvxn0USZbta08BbUETKBspIB4/a0izELB4rtZiSqo4KsoXWbYQ0ZOUZba9ZPDXn73np7P5zNINgWxM0Li/l9zi24susZbzpo+T5yKueGbqlsfISv7Lp9ESYKa7K0U8iZ6Cn65PyltyxFYkN9HnS+MTqSQsj/9ctA4bZ6dwYE3WPJGC+vURtReZ+GDWfJvYjKfXhLOHo40Gu3lF7nsLYoTpATdR5N0uMTCcKz9IaZUwhBV3EpFH6HxPlG/ry938HOtfqk0b4hmDnDSPvNuFhCZf9/Ir2Rqv4dNKLC/lu5flFs26Djmbqgl0eivVtjDNJfnPqzF0P6hKZNQthfyjw5Ekm9Zuhq5Wzamy/e1k4eFbWg1zI/xdvEQBVrM= 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/11 05:56, Barry Song wrote: > On Fri, Apr 11, 2025 at 3:13 AM Zi Yan wrote: >> >> On 10 Apr 2025, at 6:29, Barry Song wrote: >> >>> On Thu, Apr 10, 2025 at 9:05 PM Baolin Wang >>> wrote: >>>> >>>> >>>> >>>> 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()? >>> >>> For instance, when a process, such as a game, just exits, it can be expected >>> that it won't be used again in the near future. As a result, demoting >>> its previously >>> unmapped file pages can improve performance. >> >> Is it possible to mark the dying VMAs either VM_SEQ_READ or VM_RAND_READ >> so that folio_mark_accessed() will be skipped? Or a new vm_flag? >> Will it work? > > Actually took a more aggressive approach and observed good performance > improvements on phones. After zap_pte_range() called remove_rmap(), > the following logic was added: > > if (file_folio && !folio_mapped()) > deactivate_file_folio(); > > This helps file folios from exiting processes get reclaimed more quickly > during the MGLRU's min generation scan while the folios are probably > in max gen. > > I'm not entirely sure if this is universally applicable or worth submitting as > a patch. IMHO, I'm afraid this is not universally applicable. Although these file folios have been unmapped, it's not certain that they won't be accessed again. These file folios might be remapped and accessed again soon, or accessed through read()/write() operations using a file descriptor. I agree with Zi's suggestion. Using some kind of madvise() hint to mark these file folios as those that won't be accessed after being unmapped, seems can work?