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 45384C36010 for ; Fri, 11 Apr 2025 11:52:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E69692801B2; Fri, 11 Apr 2025 07:52:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF3E828019B; Fri, 11 Apr 2025 07:52:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C94942801B2; Fri, 11 Apr 2025 07:52:04 -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 AADFA28019B for ; Fri, 11 Apr 2025 07:52:04 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A048D1A241E for ; Fri, 11 Apr 2025 11:52:05 +0000 (UTC) X-FDA: 83321599410.01.A7A1834 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf05.hostedemail.com (Postfix) with ESMTP id CC4C110000C for ; Fri, 11 Apr 2025 11:52:03 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=evaE6IPG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 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=1744372323; 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=zOnn2mdi5+2ZqdQMT84rbE8zhldAP+l3K0C3RepRef4=; b=8r34+lexrZ0RSuE4CsMv0uEVDT4J8T8fViJ3R7POELgPNPDcrQlQLOuvhNupZbq+l5xt1t LhTEIFPt+V2OezGfmMLjiY+9+kQqswyXZ2XDhXWD4vza8jHK/+WjojNao3IweGUpjifxI5 PdYwa+X/z/WxQCBP1yPSz7v0uo4LL7Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744372323; a=rsa-sha256; cv=none; b=NA4dlSIvkYoMKfL/Z09g7VZQadLOZD0p9pCcsS8b54/bhlngA/OEXrBflFqag/ZjcQPlmr Yvlv91eEKuZnisrjPq8m3v5n7x2CAvY5/HEsVgWQwhAcJz4zSFqFBupAtt+/PxjfHX3jR6 wKh7RdHuEs7MQFMXbLYPq5FsFBppKuA= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=evaE6IPG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-527b70bd90dso903287e0c.3 for ; Fri, 11 Apr 2025 04:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744372323; x=1744977123; 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=zOnn2mdi5+2ZqdQMT84rbE8zhldAP+l3K0C3RepRef4=; b=evaE6IPGXS+AjzxIfKmEgayrpeCfsFjO8VPi0ngbgcn9bbzIAAcRZb1lznu3AHVhMK xiZk0xorGT8ailA+u99OvwwQRtR1mhZ6hp94cJ+iEOv+4nhkhEX1g5R9sGJX5TMkFAE5 Pfq96J77moNJVgepCJsgvSk7FHbbpslgjgWAoqcpS+BGm10wew1rqUpX3H0BOtjuz91U vdUorP65ogfW2exwiGDgsx5U8b2k7j1yqMwhArrIKDDDkLB5VIwx/mZ3cUB2St14YxhO qt++xi3XVa2MFtVdMk9WF3NFIUrtMRUHakrI7JjordOb2X3/oRJKWC1dvn6Pvw0MMw4M 1dmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744372323; x=1744977123; 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=zOnn2mdi5+2ZqdQMT84rbE8zhldAP+l3K0C3RepRef4=; b=OMb3zoGBWTdwdBWVr0wZ9jTCVI26dN3OEshMK/37XZCc3ysoN9Y9eSXo06ED+Cn5Qx KavVXO3LOcKsch7oKpNVnp7CSFhIwfGLzLmZELpS099PPtZVrywJR3VUH1WNpMpzw+pw tUYSa94E/CLBCxVhKdt0/kG9Zj8KIFGAkwfBiYTllAMFyGaKqPLBrDIEZa4l6UWsvRZP o5NQPPpjV/MOy4ePaEvSG6qr1HzkOPxArSdOJ1Ju5pGmOZ4l1I8M4Hww3VSTjWOBhv4D sIrx2Hskdjm2sqav3G0w7KevcqYO6VojsCfEN470Ngn+LeuLEsiurcjmR2vyRlNVVcR3 Zrng== X-Forwarded-Encrypted: i=1; AJvYcCVlQCoDwCjD4wZYpmp+ftTWdHploMs7t8MdSRKeR2uzCULsCeLu+aMzgXNNrggqMc9+ixriDq6dMQ==@kvack.org X-Gm-Message-State: AOJu0YwDosKu8nAHL8h9ZR26VUUpbWYFjxGIeDpsJWOOqDtK+aP9vjda kg7wVtZIi1DlFal8dmoPKf0CVb5L12DP683f6m/7d0ntr0FI3R06gW9LuHn9D3//2N2XTAci/qL Nr/rPp7kmyEwGBZIqBLjLWzirfkU= X-Gm-Gg: ASbGncuKNMqj7OCBV145se4Kv4PA4rV9Cr2a/w3MDNecs6TX+1kApz1rkqkPlt/xDNa 5us3oAplB73zR+5yH8434C/462Rbc1axBTfNQ9ngNJKJnIbtgDAITT+8jfWATu4vPgUPBtKdD9i bD+aU77yr6TafteiOwVGDahFDvVCJJjQJu X-Google-Smtp-Source: AGHT+IHUfu+oUJPp0B+gr6jUIlqDlQhVTAv6qGqFN5vBWXJ6q1aPP9DLVECfjV0kO+UZLmK9R6j1PuK+CrR19z8Ujn4= X-Received: by 2002:a05:6122:178a:b0:518:6286:87a4 with SMTP id 71dfb90a1353d-527c34b2550mr1508731e0c.4.1744372322682; Fri, 11 Apr 2025 04:52:02 -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> In-Reply-To: <6b532646-041f-4077-b09f-ff6d43aa4a81@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Fri, 11 Apr 2025 19:51:50 +0800 X-Gm-Features: ATxdqUHPHj25JVtaUNa2HuEUKQTNqHQAFH4Qp16JvBEmbecGmh0X-vJRlHJBAp0 Message-ID: Subject: Re: [RFC PATCH] mm: huge_memory: add folio_mark_accessed() when zapping file THP To: David Hildenbrand Cc: Baolin Wang , Zi Yan , 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: rspam07 X-Rspamd-Queue-Id: CC4C110000C X-Stat-Signature: pty86nksr4x97qh1j6xfkbc8if4saieo X-Rspam-User: X-HE-Tag: 1744372323-139632 X-HE-Meta: U2FsdGVkX1/mXRqGg25vhc4ypcd55DTKvPi+5OsGI0ZJ8C8bq3camQDRWJMmv0/DLMj7+BYczHzSF5VJ/OLxXo87ezsGRVIEDYVzfMmDlq8zsbtK6Ubil9XzK/inZkHxp1fhfTGPhrWLZGH3kwCnEj2aFWPvIbzJ9WY9RxYiGDTDkDoeGLg/pr/ptE/CLT7PYIbQCTV1MXXXyo/l9B+qWQm4u1wb/c/hSl0n85HpZOUfNCF0u/Z7v9doI6I9wUmldZcugJFyh7yiFCA2E8sS+VGRts3xDS4nsQvNedBlSuLDLE+c2m+V0Qhbz9mg1mNVadxBxx1kH8BntOwKKzTx8g/9YZZiYNfbvK7znT+2AFn1T126qJh4Kl31DAMEiBuw2BQIOq297M3C/IoP7l7NNe8k4vjt1OfqrOkJ4xilgzA7Br9KquGn0jQ8gJABrmA5DexF6MiUEZwtxWiP4qBRlSm5Hne8buBWhQCy7mvqaWJtR4eFld/5YjLgXPBWU48x5cml7wQcVrRunP3ldK8HHn1TreQsXdPHPsBhJFMQ1+dvJraSLREw9bpDCB8apzZxEzAu+TRthrG8zKj2vEsjUbR19YwmBqqEyvX/ykCHORF16WoF5ye0iEfp0JOjW4YAnwqWd/MvWmtjQvrQ0+gHPGr5y9ir6ZWWRIBviPqTXih6+oavts9iodg+IpvFx9R52kBXb/KWSl6gq37JL/fWzKShNLadv2vihs7VMqvrSrKpKggY7LUIqvCvuHuO5aQ+yPItlT2kJQ0k0isF9OuXbFyB6BbLYqlQ03X553S/ViJrT+BQDIRVSd4Tsmj4+8n+dY/CJhUJNZzqx/QYZvhgp9k1UUqcVx4x5VUoso3VejcNiDXBMzHG8o+6oOr8JWOW+lYm4OUHJ4lwEoqZNNbUqHONK36Ysd5UJFFRsAxQalbSd6qJ/rYIxZ2F2FXwvNxietJOeANqlwmZje8wVuP QNw5l+uq 70laA0kAH+BXPguUlreFjkmQsX38mtlPfFXvThDO7jfkMtMY/w/fmNpV2wd7H3EKUaxMcDruxQ2aD3oLU24bu3xuBytoKOE+VM2RKDj7gGGQ7Gd1UVjLp9Y6+Ja0bIFko8fP4+ut5gze3DX9p6x06t01zAxSntKkNpHhXASmGtbDrZm8F45vCFJUy1ht23cJ+lMkOpvBGTqwdx1f5FKrreLGIjXXmsihAWlrUL1j0cnU68L3BGgLFHhe07IcYnyqGymXpSiYvBUFtUtAm6M5lzEXX7MD1FXcBc/ddHjkk2yqKnh2oc1g8xunAUsUY3DvqZ4sa9stR9CsonROyWnTSytnNFoOsWYdTVA7Fi5QsHxnHrVpcmDo8dpTlXWy3fapJj64p5ojPsqRtycwZfEssgWgwHO3e6JAkoeJ1w0hM53s3TisDzAmedXj7ILs5K7EcAimLKEEhnS1DB8E= 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 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 wrote: > >>> > >>> 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-s= ized 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 coul= d 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, s= truct vm_area_struct *vma, > >>>>>>> zap_deposited_table(tlb->mm, p= md); > >>>>>>> add_mm_counter(tlb->mm, mm_counter_fil= e(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=E2=80=94specifically when= 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 be = expected > >>>> that it won't be used again in the near future. As a result, demotin= g > >>>> its previously > >>>> unmapped file pages can improve performance. > >>> > >>> Is it possible to mark the dying VMAs either VM_SEQ_READ or VM_RAND_R= EAD > >>> 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 quick= ly > >> 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 submi= tting as > >> a patch. > > > > IMHO, I'm afraid this is not universally applicable. Although these fil= e > > 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? > > 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 tex= t and other exclusive file-backed folios have no relevance to LibreOffice. If a u= ser 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. > > -- > Cheers, > > David / dhildenb > Thanks Barry