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 0B5C8C369A1 for ; Sat, 12 Apr 2025 09:03:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62D4068003C; Sat, 12 Apr 2025 05:03:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 606D168003A; Sat, 12 Apr 2025 05:03:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4572868003C; Sat, 12 Apr 2025 05:03:01 -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 2313E68003A for ; Sat, 12 Apr 2025 05:03:01 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6D4C51A10BE for ; Sat, 12 Apr 2025 09:03:01 +0000 (UTC) X-FDA: 83324802162.08.28FFDBD Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf12.hostedemail.com (Postfix) with ESMTP id 8CCBE4000A for ; Sat, 12 Apr 2025 09:02:59 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AuQuzmUC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744448579; a=rsa-sha256; cv=none; b=TYMeS5FV5pGf5zq+AipPVm3aC64YdjY029CyqFmaw8csVOHNKjTJ572ZuCRuqJcXzTogz6 Ep6QgKRnyLZS1RlpMaUTGCN09Q0j7L2A8lyTliv4yWrpTKuPBlMB2ttj5wkA3KvpM4YFuq 9hKd6yAu8L+rQ3JSP5LHlvzuCusu/Ng= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AuQuzmUC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744448579; 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=AcxM14nNo3Z+3rUutFNIH54ijwMGULjVVnVvsuIXthI=; b=eLe5hPETiz5a8+JMkeQN46nlCxTAhhg0xhZweTDIRN/hf+eG1AA6BZChxTJG1hL1xgY9+h 4k8VRk5MxF+lVIBPWxjfI745VlSnUk88+ie1+QUnTqQpQJCfoudnlsaoSiib/QzdrV2oSl HtGQOYo2LAAXns0KaCFmkWbwE72hCVU= Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-86b9d1f729eso1202274241.3 for ; Sat, 12 Apr 2025 02:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744448578; x=1745053378; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AcxM14nNo3Z+3rUutFNIH54ijwMGULjVVnVvsuIXthI=; b=AuQuzmUCjOMVherEVh/xE0wBZ1I3Sghw/0Md7w9VHVtDPwG19ncsQITxZoKiKA/QYU KFNCUmSS+X7nVyMrKgmqDr09qH4TbFeBN/ex3zG7V7dzqTImNlJ21QA/d985Gp7vcDa9 kmOioIWx2NnepyvBm1Sf2IM/vy30K/s78A4YwHy2SFfwcREJsCWWmQj7E/G4+aWRfYpg 3ebQoSFg4n2vWk5ze2yCk7TMZwo+1eYbiXPY9TC/IOYOWgNPcHmZpj8yDajNIaGvcf7u NQ85edhQmEAVkf2pdxgQ9+XoaTe/n6mHcWMC+ZJ3hSUluc43d2TEz+7rH6Je6nN1yQ14 BkrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744448578; x=1745053378; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AcxM14nNo3Z+3rUutFNIH54ijwMGULjVVnVvsuIXthI=; b=DvB8IfDSPy5rM7qnUkJCuDKOyUYBqhQ3EY4YspxQgRDaNWicIGzQXtaln+NLAEPKSm p8hNUpnWFr7umtqj5hGW3aHREslADGaTjOSerFjWUmH9W5cplm1nU+I1/ObBHLsOkk/d ZzceGH43up5tWWnGxCj3e2GxUuofl2gQNYTkgB1ZukQg1CfnFvM1zqEiFmC4GwS8Cl8p yXgZ/5Ykbcha9cpF49oemRrQq2gm+itpXs5OQAD/qFgqpFDwK4fqR+/6/QCdv9o7BmIJ 5+1DeJoIh6gTXyCVnk2xB2goLhmU4zUOyGXsTwF5nDpRlYg3MZhQVNJX0m4kKqnzMF8H 5AqA== X-Forwarded-Encrypted: i=1; AJvYcCXPFkGA2uRiV6OCmlL4vyQ1vC/BJ4BmGRiknYMgwDkXirLuTHUDNJ6viTaTB47F5JQJ4tkenhRnoQ==@kvack.org X-Gm-Message-State: AOJu0YzNN0i3pPyorVfhiz4U0u6Z8yB1qKnVLuVsqujVqkomhs4jxDYG wLWxVeVPyMuiL3XQVqbGsgaqrAre88J1bme054WwnDVvDzh/0PZ/9UK7VLa7cHe/YYtbQmc+1dY bJL8ZPtu/dc3tFXp8fqdpQ3bvefg= X-Gm-Gg: ASbGncuymFe3TGVi+yUAlp2kdNQhkqt5f6USZ7eNBm9ygVSYL41Vd6b9Sz6qBT7Yk5Z d0im+lG1GLftj0OQM7+nfq7L/65Ri5DlxwjkVRaJkHeHtMl5ZguVC8id+OcsRpxBAy27XKFdB1j A9gvBqf4MZKV3luqB7soSxRA== X-Google-Smtp-Source: AGHT+IFKEHm38FW1BLZY43Uv5Acmmj03PHFFGggtglzAfaW2DUquwBcB+ek/HbM4yTVcIwweOt3Z3CTvzGnfNUr3yPM= X-Received: by 2002:a05:6102:b15:b0:4bb:db41:3b6c with SMTP id ada2fe7eead31-4c9e4f1210emr4606535137.12.1744448578282; Sat, 12 Apr 2025 02:02:58 -0700 (PDT) MIME-Version: 1.0 References: <34bab7a60930472377afbfeefe05b980d0512aa4.1744118089.git.baolin.wang@linux.alibaba.com> <5c52b67a-8e7e-4dd7-9127-96944715d883@linux.alibaba.com> <1E123113-7A0B-4D3A-AC7A-01767D7BF2D8@nvidia.com> <247fca57-8280-41a6-85b0-03a32ea08210@linux.alibaba.com> <6b532646-041f-4077-b09f-ff6d43aa4a81@redhat.com> <97612A28-8654-46C1-A2AA-C953C7EAAE4E@nvidia.com> In-Reply-To: <97612A28-8654-46C1-A2AA-C953C7EAAE4E@nvidia.com> From: Barry Song <21cnbao@gmail.com> Date: Sat, 12 Apr 2025 21:02:47 +1200 X-Gm-Features: ATxdqUEIwclTDxyLrLgUY4k55kLkOb5lByl0eDFeGugzaoZDeukHbu7lBF_OIBU Message-ID: Subject: Re: [RFC PATCH] mm: huge_memory: add folio_mark_accessed() when zapping file THP To: Zi Yan Cc: David Hildenbrand , Baolin Wang , akpm@linux-foundation.org, willy@infradead.org, ryan.roberts@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8CCBE4000A X-Stat-Signature: 8gg65gekniiu6b9p7zewdhtswhb9wrht X-Rspam-User: X-HE-Tag: 1744448579-766350 X-HE-Meta: U2FsdGVkX19uuAuu5lTzoQ3omYWjoJMHX+oy42NtQHVTs1lt9ln/XYcX9kcuhQ8JI/cmz8uWGVo2ZNqEEEKwWGIpOztKjEMZv/7BljbPVQLAwNdlHw3IU749Q0NjmwxBWGTmpNLiFaNuVjKnVZqc/N7rNPIlQUf1mXELXAog5yZVOqPXS2jVBq2wtY14ohz44FFz2qCnVh7nYDJ0IIrsCMK3/iwnrUvFse1QGIN+nl6b4XqyGJaS/fBkxo2MkDWF5NcIYM042BpRkCEeIZy67htz94+G7s1zY/tnZ/ng8fHb66fkY9ijoGOLw/rJABOzq41SaV/6ZFVJie0Cw3V+lhU7qZMB9ZetMMrWnQGERLGWL2mJPEtf8YDtLDfs4eqftESBDIasS4n0Tj97kVHEyInBB5V9olv44vIikYP7+n0B+I7SMRnywuLE3x30pkdMJCge8Muxnc3Vj+n+7+sh96QWE8r5q87R4i6blMWw4DKPzNAnLRIac4/QB2VfoJ8AJst9IyTFDvi8sffulL7vAEe7OUMj0L9nWwyiIDGygB7hOM61sM4e6JpcWxymUCYJLjxS0PDupMk9d7tWNRfYgo8Rw+yj0rFeXc2ttxzozJCJ8kPQr/Z3WSIhrserYN81jOrmaraFK9x0bEMqWLldg5C97zvnC7P3Tn0iwLvUz4xt71QunqbiGMEQNaVJRxeKVUY276kk5CZlZYjyQTSASnj403Lna8H41kYftJ7O7WJCwPxWLVVxjH+eqO3VKqQs5alULiWvN3udsvoGeDoUcWVHZrzGVOaaoe08b7l2XRfIkmsz+Cyq4hcEtq8as89VPdIlKpnqwcZ+d1XOzgc1LKmBUGaepuA9R1tL2zLQ1/cVN4A2MyI1aktnnmzf7mjeVgIDo7poThBXr76Su7JDi2/lBAbAzBdFIFbmUyphn+5sE1FCYvSfWgQNrmYS2ky1bEJmn3TxKwtmTyOjEe5 D83YnWvm FnMeP8h7GUeEg0NOV0jovnuwxYjPrXqzsmdBm5Usnf5eP/lcr/k7Q4/jgQG2CxPqf8R0VnSjcaz1yJ6htYw4ARJMOvhpadISLgnJSBorUhTJh1phc//DVzKcWx5SXKAobnUr2X8298RRX7XKRYKIox5fdiu8KfkHw+eU7R7u8274KsiuZ5V0B7LHNnLPzh2UhjNbo5kJ8VfCnqjtZbsoePUxtSdbm3/fUkzFVlqXNkkhJjtyZZtiMfZLr0QANYoWSvim2u8WPWlQazVWmEiRi3EsASqhGS64+VO7EaUGxdI6PO+/68VNbbgW3yDPKHrqpQzlWMPHukwTusqhUKk+0EF7Pu4JtO/+zZxYFJ4D67eKQKAiIQMNxUPSzNfvIQsH4+qWE1dw02f/81nQRjiLDSLAdhZeFVXWaAX6+AJZqNwegPCoRgZcz5mIVGLiW47I04oiFrM7y2XEnWdhvzACUoTRSqdfia95yLyHc 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 Sat, Apr 12, 2025 at 2:44=E2=80=AFAM Zi Yan wrote: > > On 11 Apr 2025, at 7:51, Barry Song wrote: > > > On Fri, Apr 11, 2025 at 4:42=E2=80=AFPM David Hildenbrand wrote: > >> > >> On 11.04.25 03:20, Baolin Wang wrote: > >>> > >>> > >>> On 2025/4/11 05:56, Barry Song wrote: > >>>> On Fri, Apr 11, 2025 at 3:13=E2=80=AFAM Zi Yan wrot= e: > >>>>> > >>>>> On 10 Apr 2025, at 6:29, Barry Song wrote: > >>>>> > >>>>>> On Thu, Apr 10, 2025 at 9:05=E2=80=AFPM Baolin Wang > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 2025/4/10 16:14, Barry Song wrote: > >>>>>>>> On Wed, Apr 9, 2025 at 1:16=E2=80=AFAM 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-siz= ed folios. > >>>>>>>>> > >>>>>>>>> This might not cause obvious issues, but a potential problem co= uld be that, > >>>>>>>>> it might lead to more frequent refaults of PMD-sized file folio= s under memory > >>>>>>>>> pressure. Therefore, I am unsure whether the folio_mark_accesse= d() 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_f= ile(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-limit= ed system, > >>>>>>>> demoting unmapped file folios in the LRU=E2=80=94specifically wh= en their mapcount > >>>>>>>> drops from 1 to 0=E2=80=94can 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 b= e expected > >>>>>> that it won't be used again in the near future. As a result, demot= ing > >>>>>> 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 performan= ce > >>>> 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 qui= ckly > >>>> 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 sub= mitting as > >>>> a patch. > >>> > >>> IMHO, I'm afraid this is not universally applicable. Although these f= ile > >>> folios have been unmapped, it's not certain that they won't be access= ed > >>> again. These file folios might be remapped and accessed again soon, o= r > >>> accessed through read()/write() operations using a file descriptor. > >>> > >>> I agree with Zi's suggestion. Using some kind of madvise() hint to ma= rk > >>> these file folios as those that won't be accessed after being unmappe= d, > >>> seems can work? > >> > >> Is that similar to MADV_COLD before unmap? > > > > I'm not convinced that's the case. Although the previous app exits, > > its exclusive > > folios aren't useful to the newly launched app. For instance, Firefox's= text and > > other exclusive file-backed folios have no relevance to LibreOffice. If= a user > > terminates Firefox and then launches LibreOffice, marking Firefox=E2=80= =99s young > > PTE-mapped folios as accessed=E2=80=94thus activating them in the LRU= =E2=80=94is > > meaningless for LibreOffice. > > In terms of marking VMAs, can you do it in exit_mmap() by passing a new > parameter, like bool dying_vma, to unmap_vmas()? So that unmap_vmas() > can change exclusive file-backed VMAs to !vma_has_recency() to avoid > folio_mark_accessed(). Good idea. Alternatively, we could infer the process's exiting or OOM-reape= d state from its mm struct, removing the need for a new parameter as the RFC I sent just now: https://lore.kernel.org/linux-mm/20250412085852.48524-1-21cnbao@gmail.com/ > > > Best Regards, > Yan, Zi Thanks Barry