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 3186AC46CD4 for ; Sat, 23 Dec 2023 02:42:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C59F46B0083; Fri, 22 Dec 2023 21:41:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C09B56B0085; Fri, 22 Dec 2023 21:41:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD1C46B0087; Fri, 22 Dec 2023 21:41:59 -0500 (EST) 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 9F7916B0083 for ; Fri, 22 Dec 2023 21:41:59 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 777DFA23A8 for ; Sat, 23 Dec 2023 02:41:59 +0000 (UTC) X-FDA: 81596533158.21.2067EC9 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf14.hostedemail.com (Postfix) with ESMTP id A4F8510000E for ; Sat, 23 Dec 2023 02:41:56 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2KIgWwEX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703299316; 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=YLDWQkwvNi0zLm8nJwragHV5fsLn402XwfmayGeZHl4=; b=Tfut19fb5emEPLaDD4v5OAePbD4Jn6cTyHx9s8kDSBI6euqtSskjBUD9GloA8/P1iE2w8z 81o+Cig7MUW47TownPyJFH/WzgL8AibxFeklOzR82nlcRTkNG6MsNheP+ylij5SrsG5v9G D1uQocwDO8oRrB+K3UvoB4G/RiYuVXk= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2KIgWwEX; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703299316; a=rsa-sha256; cv=none; b=1W1HhU+qiCWx9Y+8pQfJNx/obIohqslOBr8X7pSZzsxSREDYejpTczoFNuB/QhWlK5d3W0 oykfgQMB2c5v/aZc1LzNjdQSJYt8EobKVLEgr4U9vjxrHFP6tLchB6c48oWr3drUJFSQJE 6yWc4EreumorF1PtxJXXMQ+lu/JSkT0= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-40d3b2c8517so71695e9.1 for ; Fri, 22 Dec 2023 18:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703299315; x=1703904115; 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=YLDWQkwvNi0zLm8nJwragHV5fsLn402XwfmayGeZHl4=; b=2KIgWwEXXkPJRjFrdSsrris/hvXojVw6KjBtzA4MH2BdYSeZdMkSDsvj6C/MV9m+u4 yeQlmwQ224MwRLxR6rkGWz0hOrkRfzOkGqlsH6Wn0TkFVCyKvOj5PKWwC3sx/edjMLLW BQgxnJCDUs3diy0E0kk5n3EnZDjJSeTs38i2f/2XSB6euHK5boz2x7xXiDUhxjHf5urH hpGU8T/4uvwnw/g7/AfCGfBAa/U8c+HNpyGrZGAkqWtmd7/8hQ49wSm2VOimCylBhoAw tEGf/sN2K9O4Y5BJr/03iTavfqifsYQcryo60luAyClyAE+cdse0DHixSBQ3ItsM6vSL athg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703299315; x=1703904115; 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=YLDWQkwvNi0zLm8nJwragHV5fsLn402XwfmayGeZHl4=; b=nkNxjlEU0w23wI0L2VwD9OuSbrRDzpzRUebJQA86FB1aoV7DG9uZ/6l+nF6TAfRN6S He1OCHTmdkxjx4HB/oUDJT0cKfmSIoW6o/K1bI+Md1u5HtyQekjyLpmFkImm8Ofg9zcW tLvC/vFtOlpdB8z+Q6qFvTs3lfAtLj01QFwF9d6tQ4ts+cGYP1PQIYY/TlgvU7exIIct c/A5zEEG1N4So8rDnMa12pp2AwMVzZfc/GdKybnugJ+YFlZlsHfyHgj47oP1ySc833Pu GXyq5EFRYdUPN24hAwxyAIvtUXnbjRfGVZ1RmXEio42nTBeSVkNwHo0qKnF5OMC88m5V WbuA== X-Gm-Message-State: AOJu0Yz1uBnust+VFwT8z3pMJxePD8DW5osN2n6JwGjsPcyOxNkdm4oK CUsLqUHbGz8aaoOOXDeogLCUGTHhDxDki0i4WIcQMWf0ygei X-Google-Smtp-Source: AGHT+IEyTsAQO7LAmrUqusu04fQFr3m+OzSSPJ/M1KzyJphf4IMVh3ac/mrn3nHGVMUT7MPF8Z9ah6kCT6tro9NnAS8= X-Received: by 2002:a05:600c:3b93:b0:40d:4a11:3aab with SMTP id n19-20020a05600c3b9300b0040d4a113aabmr103652wms.7.1703299314867; Fri, 22 Dec 2023 18:41:54 -0800 (PST) MIME-Version: 1.0 References: <20231220102948.1963798-1-zhaoyang.huang@unisoc.com> <1703226522421.22653@unisoc.com> <1703238070775.29652@unisoc.com> In-Reply-To: <1703238070775.29652@unisoc.com> From: Yu Zhao Date: Fri, 22 Dec 2023 19:41:17 -0700 Message-ID: Subject: Re: reply: reply: [RFC PATCH 1/1] mm: mark folio accessed in minor fault To: =?UTF-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= Cc: Zhaoyang Huang , Matthew Wilcox , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , =?UTF-8?B?5bq357qq5ruoIChTdGV2ZSBLYW5nKQ==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A4F8510000E X-Stat-Signature: zp4f4xhpcizpem6rqkr3y1uw8tw8b1ad X-HE-Tag: 1703299316-25672 X-HE-Meta: U2FsdGVkX1/E7zOhhcU4LrMqiV23v3Mg0tW/jUDslSQlTtYbrxnbWzxoDYD+VxgGOAJ6bYrswBVEgZHxueG7gXObhr+7n2Td6lK9KRKufA/qQp5mBBhMhmZ1+20jPOw5IL7V/lkuIj/NkOx9qFt0+l7JUvo+/E2e1/YdQT0De7Dw8ZDsTcuSx7XZ5fSnW7hxC3aklAmRf6pgw1a/olVPTJK+sYGEcm9D7sVxxlLloixzEqFV+H5QjZRekezHbabzG4CZWj4GCVCOJ/AIUPDWUgiqu9crZTQ92ndYituintTtFKWnQtGfp3VpZZYgGs1nR8NeuJFHDhID4FaJby9W7cTxEUB4jcpzv5+s4wfIarKxzM8Bqm7yrc0xBgFWK887c6npG9r0BfQEaC6u6Hcw2sGqJG5A5UUoROuj0J6/uKQznpB151ZOZyfQn7NX6Duj/BrDw5GyuFac7JvdtkFywzrGZ3QjDOIqZMQAuGofN2vjkrc80jl6QqoQUvG8tOnLsCAvVRovaQu6sFutYJdouR9KQr+J4eUYlHty1H8q9X5L620p5RLK5/JxB9llMFUQUStmVUUYLkRHJMj2DurOrrvbpC4XleFhdSWDGWGUlcofMIhA8Lt62y2iKFu6oJmIJfmQRoG7eCqDKEpPxJZol4T5QNT1lWv3K+BMTfw2vMb9gPMviU406nNDoaECtuCr436/ELZ5oCMGZslS4NiBMStxpizF/aSX1XMSoMqRDvsWo76gl7Bp17hY02deQlGL0skuBXhPRFebXiiREojZSDFrgtCKyLl/Q6acg9BeYuUqs1FPMNPJC9PO5VgetdvuRZyMUuxO3cIbzklsuC0lkMVBk4LmSMY7CGU4DmWUawUBUMJP/ubxyw9a22E7f35hXaFJjAlh3mzs5CBMwgq2S0oKlNAsP1p+LpcC4BeU9vOCve9n+isWXgiP8CoL5/R/IAW7t7BdRULEJg+BzL5 mfYaFZbK TtJCYTPC7KhQm3W8FtHLPfFhx5gfGu8/9mMnbCWSo0sWXgxSyu8FOD1u9iH6/lnvvjI6xHRlIKakMdv7WSrdKfpi+xoEQ6SS92nvrBR2CZePFX7UEGCvOInDJgiZMH7UCGwZ4WJLz2FKtKumVMptl8Pss5n3xgVP0FpyI3cAofBx4W/ONIwX6+bJsn7IPi3sSg/XzAeTJ/WnIB+TGt1id0rQgaCJI5W9kmD1EaTl5+qY1zvPWf8/BNrywSjZiNKzDbpU/Ni3Sk6BI/KhfxX4SVH5cg7VNmvX4vR9bmUemuq37h6O0Vtnfn9sdfM1fhQtgkBg5QtuzVI+lSQQUOhM74Q6Q6zoi2HiJzU8/dkHGNfe/RDZuIosu9Q3Kc/Ybr0wZsdjcRYVVt2JMWcka/ltFhCRpEIPNfUWnC0b8Al0ynEHwmokCNl6IaqKueQ== 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, Dec 22, 2023 at 2:41=E2=80=AFAM =E9=BB=84=E6=9C=9D=E9=98=B3 (Zhaoya= ng Huang) wrote: > > > > On Fri, Dec 22, 2023 at 2:45=E2=80=AFPM Yu Zhao wrote= : > > > > On Thu, Dec 21, 2023 at 11:29=E2=80=AFPM =E9=BB=84=E6=9C=9D=E9=98=B3 (Z= haoyang Huang) > > wrote: > > > > > > > > > On Thu, Dec 21, 2023 at 10:53=E2=80=AFPM Zhaoyang Huang wrote: > > > > > > > > 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 wrote: > > > > > > > > > > > > > > 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 wr= ote: > > > > > > > > > On Wed, Dec 20, 2023 at 10:14=E2=80=AFPM Matthew Wilcox <= willy@infradead.org> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huan= g 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 affections: > > > > > > > > > > > > > > > > > > > > > > 1. NR_ACTIVE_FILE is not accurate as expected. > > > > > > > > > > > 2. Low reclaiming efficiency caused by dummy nactive = folio which should > > > > > > > > > > > be kept as earlier as shrink_active_list. > > > > > > > > > > > > > > > > > > > > > > I would like to suggest mark the folio be accessed in= minor fault to > > > > > > > > > > > solve this situation. > > > > > > > > > > > > > > > > > > > > This isn't going to be as effective as you imagine. Al= most all file > > > > > > > > > > faults are handled through filemap_map_pages(). So I m= ust ask, what > > > > > > > > > > testing have you done with this patch? > > > > > > > > > > > > > > > > > > > > And while you're gathering data, what effect would this= patch have on your > > > > > > > > > > workloads? > > > > > > > > > Thanks for heads-up, I am out of date for readahead mecha= nism. My goal > > > > > > > > > > > > > > > > It's not a terribly new mechanism ... filemap_map_pages() w= as added nine > > > > > > > > years ago in 2014 by commit f1820361f83d > > > > > > > > > > > > > > > > > is to have mapped file pages behave like other pages whic= h could be > > > > > > > > > promoted immediately when they are accessed. I will updat= e the patch > > > > > > > > > and provide benchmark data in new patch set. > > > > > > > > > > > > > > > > Understood. I don't know the history of this, so I'm not s= ure if the > > > > > > > > decision to not mark folios as accessed here was intentiona= l or not. > > > > > > > > I suspect it's entirely unintentional. > > > > > > > > > > > > > > It's intentional. For the active/inactive LRU, all folios sta= rt > > > > > > > inactive. The first scan of a folio transfers the A-bit (if i= t's set > > > > > > > during the initial fault) to PG_referenced; the second scan o= f 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 "prom= oted" on > > > > > > > the second scan. This RFC would regress memory streaming work= loads. > > > > > > 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 triggerin= g minor faults? > > > > Please find the following chart for mapped page state machine > > > > transfication. > > > > > > > I'm not sure what you are asking me to look at -- is the following > > > > trying to illustrate something related to my question above? > > > > > > sorry for my fault on table generation, resend it, I am trying to pre= sent how RFC performs in a page's stat transfer > > > > > > 1. RFC behaves the same as the mainline in (1)(2) > > > 2. VM_EXEC mapped pages are activated earlier than mainline which hel= p improve scan efficiency in (3)(4) > > > 3. none VM_EXEC mapped pages are dropped as vfs pages do during 3rd s= can. > > > > > > (1) > > > 1st access shrink_active_li= st 1st scan(shink_folio_list) 2nd scan(shrink_folio_list= ') > > > mainline INA/UNR NA = INA/REF DROP > > > RFC INA/UNR NA = INA/REF DROP > > > > > I don't think this is the case -- with this RFC, *readahead* folios, > > > which are added into pagecache as INA/UNR, become PG_referenced upon > > > the initial fault (first access), i.e., INA/REF. The first scan will > > > actually activate them, i.e., they become ACT/UNR, because they have > > > both PG_referenced and the A-bit. > > No,Sorry for the confusion. This RFC actually aims at minor fault of > > the faulted pages(with one pte setup). In terms of the readahead > > pages, can we solve it by add one criteria as bellow, which unifies > > all kinds of mapped pages in RFC. Again this is still wrong -- how do you know the other process mapping this folio isn't also streaming the file? It'd be best to take a step back and think through my original question: what prevents a specific *access pattern* from triggering minor faults? The simple answer is that you can't. > > @@ -3273,6 +3273,12 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) > > */ > > folio =3D filemap_get_folio(mapping, index); > > if (likely(!IS_ERR(folio))) { > > + /* > > + * try to promote inactive folio here when it is access= ed > > + * as minor fault > > + */ > > + if(folio_mapcount(folio)) > > + folio_mark_accessed(folio); > > /* > > * We found the page, so try async readahead before wait= ing for > > * the lock. > > > Please find bellow for the stat machine table of updated RFC, where RFC b= ehaves same or enhances the scan efficiency by promoting the page in shrink= _active_list. > > (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 > RA 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 > RA INA/UNR INA/REF = NA ACT/REF > > (3) > 1st access 1st scan(shink_folio_= list) 2nd access 2nd scan(shrink_active_list) 3rd scan(shrin= k_folio_list) > mainline INA/UNR INA/REF = INA/REF NA = ACT/REF > RFC INA/UNR INA/REF = ACT/REF ACT/REF = NA > (VM_EXEC) > RFC INA/UNR INA/REF = ACT/REF INA/REF = DROP > (non VM_EXEC) > RA INA/UNR INA/REF = INA/REF NA = ACT/REF > > (4) > 1st access 2nd access= 3rd access 1st scan(shrink_active_list) 2nd s= can(shink_folio_list) > mainline INA/UNR INA/UNR = INA/UNR NA = ACT/REF > RFC INA/UNR INA/REF = ACT/REF ACT/REF N= A > (VM_EXEC) > RFC INA/UNR INA/REF = ACT/REF ACT/REF N= A > (Non VM_EXEC) > RA INA/UNR INA/REF = ACT/REF ACT/REF = NA > > > > > > So it doesn't behave the same way the mainline does for the first cas= e > > > you listed. (I didn't look at the rest of the cases.)