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 5C00DC3601E for ; Thu, 10 Apr 2025 10:29:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A85052800EB; Thu, 10 Apr 2025 06:29:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A34C52800EA; Thu, 10 Apr 2025 06:29:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FA772800EB; Thu, 10 Apr 2025 06:29:42 -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 716912800EA for ; Thu, 10 Apr 2025 06:29:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 309B6ACF69 for ; Thu, 10 Apr 2025 10:29:43 +0000 (UTC) X-FDA: 83317763046.22.F4FC091 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf23.hostedemail.com (Postfix) with ESMTP id 7F839140004 for ; Thu, 10 Apr 2025 10:29:41 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jjtEpnsj; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744280981; 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=wsL9mz5VLosJIEplm0FTk8FQNVbT/vTDpv3BHLI4ivk=; b=MOrwk3fX3vIkPrp+nehVV+aK7253eoRJxT81O6QfvlluugrXgTLNp7bmeh/kHSe0u9e/I6 8Qddx59LhLGKRdPw15/W5KoWjiQm2gmkjv5wRG/IG6Ml+K6924PDIqkXgghoc4j1qPW2Bd oF2vr6FXEniKjHASWuLvnc3waPlSids= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jjtEpnsj; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744280981; a=rsa-sha256; cv=none; b=iDuiGZnjMTcEOvETHQajH+xZeBlRZU7HwWKoZD3eoX0nxOs6P8KKdDPAR/aXMFZsVlvM3q cNFHCIusKj2DJWgxTTZ/pJ53EV7l/Zx7s0eflGEghMVHrfwiil2IU1AEYUYAzczFsSSGHs Tlkzq/PJR/zCxppZs2WeOTVUUkUK+LA= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-86718c2c3b9so252889241.2 for ; Thu, 10 Apr 2025 03:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744280980; x=1744885780; 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=wsL9mz5VLosJIEplm0FTk8FQNVbT/vTDpv3BHLI4ivk=; b=jjtEpnsjikEcc3GOMfkykbt2P567CMX56x5JZ5R1vo5zrulyiazGArMD4xJnN87X/6 PZLb17TW82abMbmsp71wv+cD51krIvoFiRMcNgGzGsTeGrkndHpALTw3OYkIe7hsvS8m xSAAMHA3ZqJexSmc/lCHiwUAJSXD15S2swPo3vQqJOd/qck7oPGpC1afYuYzojnFza1y WJy72iX4qJcepsYg9IrcJ8qA3QDNPOfJWryO6Yer2oD4oukaFiOuT11mQYjeHZbpW/by h1ZknbuoKjo1tJQyq8hvhvCvU6FaQ6zTNEsBDVyXLEJMPBf3EsKIdGeSXW6gFPsE2AvV Nh9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744280980; x=1744885780; 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=wsL9mz5VLosJIEplm0FTk8FQNVbT/vTDpv3BHLI4ivk=; b=cumgDGWQyb1HVOOO399aN64Os+6Wzk5lNrK3e84N+ghlBWGn0VPwJr1YrhjDU6FRE2 SLeI6hBrpWiDoIQ9bWWlE05Z9cvOPIFMxFLfbTAgR5APT/8SNEhV6exUnRHPhRogG7a1 58qliF+b0mK+RgeXMdQLZYDlix/q7mUafYfKSUwkTnCSoDyL08VIrASPRR/dPqfrvJHN OmuoGI7YG+I9hVOm0ZG93+6zqGADZeGydk5mhqJOIcVya07ml5oiSv18b9l1i8VI7O5V 4gQJgbthfQxv1hDLKZchxmcIOVTVx5jm9/dMQZmDxuPNA48x7bisSf1hdXxAHL6x4Dhz PqdQ== X-Forwarded-Encrypted: i=1; AJvYcCXLr0MYsAeEJk6dd7SNvqXArTnub0bOFPCAxrOt440KVkcEYYTLPqnu3/MAB7gGEdCoBwVjftX3Qg==@kvack.org X-Gm-Message-State: AOJu0YzP+YcbSld8uWNLdBsXCOPuNZSP40PdREyPQJc929HTfmyA2LOj pmPPxE4znluHRTxp0t+hByMA5q2zoVGPMIbBqk7R9l7R2rcwCaBMPqF8MzELrSqhGnRdZiI7J5f idJpL8PzdE3VvivnnQ2/ZjEesKR4= X-Gm-Gg: ASbGncv690eTJtWP6QddycYFMOt/vcueE5ljmRB2vspJ+wFmhSAtXC6oFGizT9alw9d auVoKV1ZT8CQu+hWHddxmwYpkhqziD5YJWf5aN0TI3pRLBnCJNfRnmPeT91wtDDzvLp2fSD0rwq oynFyxnKWCUuKdvGUsCgx4QMGlauoquy3H X-Google-Smtp-Source: AGHT+IHMjsL14UIkB6GS65IXtIabMPfJfm7Q8qzDjxnRqvscrD+A/dh2YPBdp92joEmfmuIbRzv6rYVqFbcZMsw8Kro= X-Received: by 2002:a05:6102:32ca:b0:4bb:cf25:c5a7 with SMTP id ada2fe7eead31-4c9d34ad25cmr1434299137.7.1744280980461; Thu, 10 Apr 2025 03:29:40 -0700 (PDT) MIME-Version: 1.0 References: <34bab7a60930472377afbfeefe05b980d0512aa4.1744118089.git.baolin.wang@linux.alibaba.com> <5c52b67a-8e7e-4dd7-9127-96944715d883@linux.alibaba.com> In-Reply-To: <5c52b67a-8e7e-4dd7-9127-96944715d883@linux.alibaba.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 10 Apr 2025 22:29:27 +1200 X-Gm-Features: ATxdqUGpjL6YVwRw3eR-_HonqCL1J4sjOeI6Lcqss7S7Xw9gUU1f7F6JBXetElM Message-ID: Subject: Re: [RFC PATCH] mm: huge_memory: add folio_mark_accessed() when zapping file THP To: Baolin Wang Cc: akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, ryan.roberts@arm.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7F839140004 X-Stat-Signature: itgkmwxocsu4jcsjyg58drmkmykhn57p X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1744280981-702738 X-HE-Meta: U2FsdGVkX18T2BgfaoxKQk3nve7PAi5TGTFRbnRtzAStc6fkWxVKDk2XncX5FCkLwz5Hu1rHO4pWabBvrwX1DUepKSDye8LA4k5OYcbA0mP4VmADMyL3pFBkQaa7T7NPgakWdqk3NixlT3N7KBrmzX34x82lEMSkZZHoqKUEiPkf3y4u4555bEKAbFjiCO5+Vc7FrY7oqEHD3coe82ojKH/sM0eCHRn5WAdG4JvlHXIPVwXYfQ6pTX3kSdxaDTrLBtambqS+CP364XZjpKWQLxiYhTYuukb1uhKdTJ8czoKAJh/9F1Mfd9uKauDzPmIsJsxGDbv5sFwr0m1IKOA3FG0qDSBPTX2DHttlD3uTaJA0M1N9ZCvmShThyROY57TVQY2r/EH9v0bHtsqvKR3QVJGr/twpQ4wVmnBKp894/gr818LgwS+KyfH6JNUxWiCiDwTb0iB5n0VP2UxjPJNqwlRo6Ba9/p00Nar9PXoQBCrG+8zmbooQL+J5d4WGG7GcUZwweMmKLYm/pRN9m8HW54chWNa0OdYtA+gWdeF2ceFARn/nXUIraAJxABAsJK695TI903DcUn+3qF+tLJL2oLWJX+S7zqWG69XmfuMaiuG5U7R0hilN4YooxVZ1OUxcqQ6qUQz8qSHm/cqzsyOApXgYua0entN7AWPTOmf/8bKs1n8kCrmcWNLFCAyPm6PvLLFlOuzCH8ItPuAeTz6LE09p0GO5Mnw2u+kcWJCAkvN54tmrwjtFzHcTquI6aNnstnrirhCgK9ihDn3Cc9b4hFdAndUNwImRqWLK+o5Wb0nqiNQWgmMpJzelnB0D6iML0aH30A6UunstBG7g4jTW8WFRlpLMU3rIm1U0L/zBHvRl9qTjUMxYQjhRxi74gPjHDzExA2AQg4J1FgexWu0QPUyMRWJG4ohM1lj0Q5knCMXIrt4YEBCP5S4md8d8WYtxbX+q/q6MC7cdJeIfNN8 7FW/EDzj VKEDKfRjP4YkVYquMpAl90ELFVQ== 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 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 notic= ed 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 m= ark the > >> folio as having seen activity, but this is not done for PMD-sized foli= os. > >> > >> 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() sho= uld 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 syst= em, > > demoting unmapped file folios in the LRU=E2=80=94specifically when thei= r 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 expecte= d that it won't be used again in the near future. As a result, demoting its previously unmapped file pages can improve performance. Of course, for file folios mapped by multiple processes, such as common .so files, it's a different story. Typically, their mapcounts are always high. > > > If others have observed the same behavior, we might not need to mark th= em > > as accessed in that scenario. > > > >> } > >> > >> spin_unlock(ptl); > >> -- > >> 2.43.5 > >> > > Thanks Barry