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 50C27C41535 for ; Fri, 22 Dec 2023 05:53:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAC8E6B0080; Fri, 22 Dec 2023 00:53:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A5C5A6B0082; Fri, 22 Dec 2023 00:53:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 923DF6B0085; Fri, 22 Dec 2023 00:53:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 81EB76B0080 for ; Fri, 22 Dec 2023 00:53:34 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 41E12A02F6 for ; Fri, 22 Dec 2023 05:53:34 +0000 (UTC) X-FDA: 81593387148.15.599C150 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf02.hostedemail.com (Postfix) with ESMTP id 554648000B for ; Fri, 22 Dec 2023 05:53:32 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DRp8AF9z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703224412; 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=qCXnfWI0LxEg9yxOXziwsaTzEl1G0IzRUjonaTXiIjk=; b=RSIYApZd9hjaA/v9xMC4IppUoal/2LiN2IqnKiNEpBG65SiNS6XZGTJt/zsssbslAmRwbT DwCiDVe2dErjXKwet4zB1MArMd3FStOtxrpprdylWoAFUblJMX//Vw1BMQleYtXsQ6o9VO wfRRHZ186XR/IjVGcwAY7LJvK2ouZsE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DRp8AF9z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703224412; a=rsa-sha256; cv=none; b=7ojYs7JgoVc/r5Kkcusdh2/lr0SW3Yz2jx48/oEoFMl1x0SwsmE+AM+kdctaNOLZaqJIeo aWfP4h6H+7XXek2zccj0vI0BvaUcg+LWorvNeu1LLF9uc5TGe6O4YkgI8xcgXM1mDK0EdD n4JPpDDo+ag30R/33wtBxbWtGsfMWFw= Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-50dfac6c0beso1975874e87.2 for ; Thu, 21 Dec 2023 21:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703224410; x=1703829210; 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=qCXnfWI0LxEg9yxOXziwsaTzEl1G0IzRUjonaTXiIjk=; b=DRp8AF9zz7BdR7/dCzQSKrRIUiuTzU8irZbkKqojlRxjFu42ciUv9zS4/tpuu4sTEF L3vl8DUiIbw7CedYkyZA+3w4yJKodhmkpsGXukfM8xk3iX2GsxFfcjqsVtq/xl7fCDQZ AK6Lv1YpTch7a5MmAH3vWm7Q8QthhBb9JqXoMZkjjI1B8Zx9f2IwUquxAaC8PzKcnvDT UTy/VrzA/D63x6RGa3Gln2MPvQzVGuEdpIq8aJGua6R5KEPMgSUE0hRTdDIgttrpjdgA vZgb1w+SvdhiZM8dwZppzagq1s5FD0tqn2nYVKvp7M0UgvP2P/5OMiIJ7yDBKH06I6M0 vSJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703224410; x=1703829210; 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=qCXnfWI0LxEg9yxOXziwsaTzEl1G0IzRUjonaTXiIjk=; b=FqXRMkej6RPkNuhBB/Bmcu35LbNzqvpkwtyn2Cbh7rmCRdMguGlwzkuyMw7YpHJrZx CCXS1TsZUeKeM+8tCnpSkT+JhabEqK10HbHZSfGi4A8IJ6+yT9AFRB9Qr4t95JmrHGlP q+R240YuyvACzv+TKfnAbIC2qfLHE2D4WR+SkMtyArLIxpWsQf4W0t9VfkaSWjCmP1NC +fyJbyLXfUiTQd4yC69V6uGmQ2cERyu+SgPl/GIDn+b/HncBPduSrLJI4ZQcRoxeWfw9 l/ly/aJUczjnikZp9+Msb7magPoed5D/qC2yRR/kl24PZ8e9qx93Ys7SCYg5p0v3qvcV U2UA== X-Gm-Message-State: AOJu0Yy1OtSylgxEy+vU3NYnUJPOlPxhE8q9h9VelFCztLtl4M7Jsurh a7AUq1q2fT7BGkxEjWp93DddIZCcR/isviXpkaI= X-Google-Smtp-Source: AGHT+IHKTJQV20SqN966boq3YGZXb9F2xuhOMuEW9nnI1UdL30Ja2FCgktsO8PUQmrOO9RXatIMRUO6e7i1G/X8p2rQ= X-Received: by 2002:a19:7611:0:b0:50e:4b94:61b0 with SMTP id c17-20020a197611000000b0050e4b9461b0mr367462lff.56.1703224410197; Thu, 21 Dec 2023 21:53:30 -0800 (PST) MIME-Version: 1.0 References: <20231220102948.1963798-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 22 Dec 2023 13:53:18 +0800 Message-ID: Subject: Re: [RFC PATCH 1/1] mm: mark folio accessed in minor fault To: Yu Zhao Cc: Matthew Wilcox , "zhaoyang.huang" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: maicef1wr1md7owht6x95b5hwu8wjckf X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 554648000B X-HE-Tag: 1703224412-555690 X-HE-Meta: U2FsdGVkX18GmPvGzhyAHgudHxTex82lnpTDIzjS4tDXsTpjA3wL3UVpahcXSX0XeNXQf9zH6gNTE6i5Lw98rd73BA5PqAdgmU05WeWewkrXbAoTgDgU2B0g+hNNG0+WW4Ok6am2O5hBmEM3i/F+TwVHwonXTas9gHTH08xFbeTFqYFqsWERu7mvm8SFEucHceiCAqyBSvd/PnJNHuvCG4Z9b1lUSaZIYiPOjyCjIpt+q+gYhPTFmTHcHyl4oG51rioI3yQ10c/CRcXjv3cjdsPGSpQE6jQglgP2ava/jx6CR5EtrO0IU1aFxZ7Fdd4FZBy4caLg9tXEOGAPNfMM2LGN17ZlezyvQIkoZnnRMe4CbMzzaNbw7cN7cSJRaTwpvlS8jUSIk5vSXSucC/7AW7rNF8ZjR2BGgctqSvQMBKZYyZAUsJYlS3dg+pDyn40Ww+tRMeiKMAD5VHQMMUrcCQsTRv9id2g15/15NL3XKuhSSOyhU6ONfVrVMrOcTDn/midf/soN/UGO2GoAltpAJTL1gG5H+lrUp6b34zNnKMHIZ9HQjBBashrVGBoeMId12OUhnhdcHhCu+VTs5LToxBXz/YzJtw6qRVZ69jReGgwsxjsEDzu7m8KeaVIQfdSWstuV9EcNP5v/AAVKnnySiaqQnQkgdWp8e8qrmKZaOmJgQ2QfGnV6Rz8PVHiwRa/BGF6V/4Dat9pfOARWlZBOWhX8wXjLX4PyknT/w/2F2ixvFPs64pi4VRO0y5R5P2EwzfiguOwF2LBghurMbE0uqS6kUwhlCwRdK63rd1HBCc+GdULF503G6a2fWdcxxHgLaXFNg/G6LTMVN4tknGb6SKXACNm6thwl7D2y0X+5gn2SCssXdEETinvns07YbdeLqsOOXc/iTljgjf9wSyOqJbe8zqtdV7y0wfRmPvYNZp293qnVaqpdzafOsOmHCw+WW8I1DZNtUBWiTbxy+fG wrajH28U JLz8iM3UABdLvex6zqPqdf4ot9kM1i8C6EMfzpJVaPnZLpgJVDRqXGL0wropZNDv+yYLmttgOsfNi0I5ykv9QWKXoXnp0PBo2YrgIXhwr+cYGe2Sp3L779T4Jg50fTK5QPZpCnxtWX46+u7MmOWdmzP+VBJjoH5GHxfLDkOuOBIEL3cRAk0KLqaYCPILRvTBLA/L25YW1aiEsbxbwmBxmTjZOVr7q7o3YvqL8Q1IR57M4RHi6j+vjxgn8MneKfAQ7HvOXRSjjVSevrsHm3Aj1vAGIe6r840oCxRJ3aY0JiAd9YL+tbrSiUD0SANLL9W0pQanjlQ2UvwRexHNCJ+BfDeaGnFv5Ra0ACYXdlPbxdKqxeExwzd02vVy6d9/8HHtc+e9qGt1jlxW95y6Vh3clq3ibS0YbLmO4x6ssZaCegXxV/NficTTwax2T4/hLisQsEX8QFX1V0zdREtDV8nz7WmIWof+ApWurLbirQVlPHhcvyyNKPv/4PrZ6WTQrYv7x9LHTAPeTihPUs8k= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000042, 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, Dec 21, 2023 at 2:33=E2=80=AFPM Yu Zhao wrote: > > On Wed, Dec 20, 2023 at 11:28=E2=80=AFPM Zhaoyang Huang wrote: > > > > On Thu, Dec 21, 2023 at 12:53=E2=80=AFPM Yu Zhao wr= ote: > > > > > > On Wed, Dec 20, 2023 at 9:09=E2=80=AFPM Matthew Wilcox wrote: > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > On Wed, Dec 20, 2023 at 10:14=E2=80=AFPM Matthew Wilcox wrote: > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > From: Zhaoyang Huang > > > > > > > > > > > > > > Inactive mapped folio will be promoted to active only when it= is > > > > > > > scanned in shrink_inactive_list, while the vfs folio will do = this > > > > > > > immidiatly when it is accessed. These will introduce two affe= ctions: > > > > > > > > > > > > > > 1. NR_ACTIVE_FILE is not accurate as expected. > > > > > > > 2. Low reclaiming efficiency caused by dummy nactive folio wh= ich should > > > > > > > be kept as earlier as shrink_active_list. > > > > > > > > > > > > > > I would like to suggest mark the folio be accessed in minor f= ault to > > > > > > > solve this situation. > > > > > > > > > > > > This isn't going to be as effective as you imagine. Almost all= file > > > > > > faults are handled through filemap_map_pages(). So I must ask,= what > > > > > > testing have you done with this patch? > > > > > > > > > > > > And while you're gathering data, what effect would this patch h= ave on your > > > > > > workloads? > > > > > Thanks for heads-up, I am out of date for readahead mechanism. My= goal > > > > > > > > It's not a terribly new mechanism ... filemap_map_pages() was added= nine > > > > years ago in 2014 by commit f1820361f83d > > > > > > > > > is to have mapped file pages behave like other pages which could = be > > > > > promoted immediately when they are accessed. I will update the pa= tch > > > > > and provide benchmark data in new patch set. > > > > > > > > Understood. I don't know the history of this, so I'm not sure if t= he > > > > decision to not mark folios as accessed here was intentional or not= . > > > > I suspect it's entirely unintentional. > > > > > > It's intentional. For the active/inactive LRU, all folios start > > > inactive. The first scan of a folio transfers the A-bit (if it's set > > > during the initial fault) to PG_referenced; the second scan of this > > > folio, if the A-bit is set again, moves it to the active list. This > > > way single-use folios, i.e., folios mapped for file streaming, can be > > > reclaimed quickly, since they are "demoted" rather than "promoted" on > > > the second scan. This RFC would regress memory streaming workloads. > > Thanks. Please correct me if I am wrong. IMO, there will be no > > minor-fault for single-use folios > > Why not? What prevents a specific *access pattern* from triggering minor = faults? Please find the following chart for mapped page state machine transfication. We can find that: 1. RFC behaves the same as the mainline in (1)(2) 2. VM_EXEC mapped pages are activated earlier than mainline which help improve scan efficiency in (3)(4) 3. none VM_EXEC mapped pages are dropped as vfs pages do during 3rd scan. (1) 1st access shrink_active_list 1st scan(shink_folio_list) 2nd scan(shrink_folio_list') mainline INA/UNR NA INA/REF DROP RFC INA/UNR NA INA/REF DROP (2) 1st access 2nd access shrink_active_list 1st scan(shink_folio_list) mainline INA/UNR INA/UNR NA ACT/REF RFC INA/UNR INA/REF NA ACT/REF (3) 1st access shrink_active_list 1st scan(shink_folio_list) 2nd access 2nd scan(shrink_active_list) 3rd scan(shink_folio_list) mainline INA/UNR NA INA/REF INA/REF NA ACT/REF RFC INA/UNR NA INA/REF ACT/REF ACT/REF NA (VM_EXEC) RFC INA/UNR NA INA/REF ACT/REF INA/REF DROP (non VM_EXEC) (4) 1st access 2nd access 3rd access shrink_active_list shink_folio_list mainline INA/UNR INA/UNR INA/UNR NA ACT/REF RFC INA/UNR INA/REF ACT/REF ACT/REF NA (VM_EXEC) RFC INA/UNR INA/REF ACT/REF ACT/REF NA (Non VM_EXEC) > > > which means RFC could behave the > > same as mainline does now? I think it doesn't make sense to have > > multiple-mapped pages filled in page_list to shrink_page_list since we > > can distinguish them in advance.