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 6955EC41535 for ; Fri, 22 Dec 2023 08:41:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A0916B0092; Fri, 22 Dec 2023 03:41:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 050CB6B0093; Fri, 22 Dec 2023 03:41:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5B126B0095; Fri, 22 Dec 2023 03:41:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D564F6B0092 for ; Fri, 22 Dec 2023 03:41:37 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A862FA07F3 for ; Fri, 22 Dec 2023 08:41:37 +0000 (UTC) X-FDA: 81593810634.19.4F35DEA Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf29.hostedemail.com (Postfix) with ESMTP id BD4DB120002 for ; Fri, 22 Dec 2023 08:41:34 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GaECo8W8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.48 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=1703234494; 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=P66lBpZdkUC3/1oyh59gObPlC1U1DYIHSlxdNgyPt2M=; b=Ys+xx3i4lu2cuwozoXi0ITJOXAEDM81ABXuK5zlP64Tmjw1AKlQulS/NBsmfnVgNXK1zUK B0uO13Q5KSaQywtt20SOJ6t3EGPfyGIwb908n3lR77B+9Ruh2e9bBERfkywWf9QLh+x5jj Gm9L+7MOtmgrAwsBVkFJpdORDTheWiU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GaECo8W8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703234494; a=rsa-sha256; cv=none; b=m+nXsd4ME1BJuKw7o7pJMA3F4j2AwbtfvXyPHMyYwcr5NgHzuvOerqCW9Gvar9agkBz9y0 v0UixUgUhkcsRssvAHEzTdjYPp7fIMHdGElSKP4XPDBYASY8D5DbleV31xrgNHJQ4g8IkJ ttRZr60bWwi2X+S2f9EvzmLDRohufoc= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-50e62c1245eso1422622e87.1 for ; Fri, 22 Dec 2023 00:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703234493; x=1703839293; 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=P66lBpZdkUC3/1oyh59gObPlC1U1DYIHSlxdNgyPt2M=; b=GaECo8W8Wkre3S6Bavl6rWOlenKTo3zVMA/3Z81DDi2U0i+v1bW3LN1PABKmGrvyGw SmIMb68kVOtBEH0bMWO7p8J5BUMFMfmIComcGrs4NnHjYrMtmO1rSCdSSVGCiFX+br2s ne0pYkCOZx+EVtIuL2leT9niGyzZ0ljdGXV25nfKk/YZyOmnE7S7S0fdpY5wulXfQQJw APxZdQr1Zqhp4DsXHIyOwCmqE3pYytQvJtxDZSUT1chc7YJeX4rsKFCL42euTkPM+C4q LSi6QehbOwOB2E6U3Edxf/YxEdCxMnvaDnMDLhL4LQEBAcPvN69zculkIGJ6DC7gFKzP P4eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703234493; x=1703839293; 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=P66lBpZdkUC3/1oyh59gObPlC1U1DYIHSlxdNgyPt2M=; b=KyCO5/QxIKrV9Dk74bU6KlJqaYHXomfJaOAV+0TOXqJmtiKzlgOZSImv9yF0lyc7iJ SfXyc9mIi0UnT3jwtELg9ikTzwtaVVfFloXXGI3qcAhhqxQd1LSPuMlBg4EpBOwLA4gw JsX5wvHBqHUyKYGeKtcF8d7nJQFBxwahbCCkjkxwamm9wPVkDQYDb8I8dxMnsrqjS+BN pn4Y04r0UTb+WK0XjNqV9DvX22R9TZy72SraA83ljAyer+UjWmK/oahQBPy1rFbHS7HC tzRxpz32XkXA9a9OC/Bv7BBmh15ibm4Evqo/K2s3+NU4S7aNovw9k/A/YEZs90wBFShh Q/BA== X-Gm-Message-State: AOJu0Yx74YWtdW61zJ5dbHtV9MvNLONpvkoY1/x8j7kG6QJVpVJSfuhQ aj0mTvOQsfrAQluNdAl5h3vXGUUah0EfCOZ0i0k= X-Google-Smtp-Source: AGHT+IG2nrQT3foanUnBDZVtdIc5X3o9EFTz/b9SndXd+0GOCOivRJ6tmv+4kccebxc2Y2oksPWMA8AWqQNwPvkeftA= X-Received: by 2002:a05:6512:208e:b0:50e:6878:a71d with SMTP id t14-20020a056512208e00b0050e6878a71dmr362356lfr.44.1703234492506; Fri, 22 Dec 2023 00:41:32 -0800 (PST) MIME-Version: 1.0 References: <20231220102948.1963798-1-zhaoyang.huang@unisoc.com> <1703226522421.22653@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 22 Dec 2023 16:41:20 +0800 Message-ID: Subject: Re: reply: [RFC PATCH 1/1] mm: mark folio accessed in minor fault To: Yu Zhao Cc: =?UTF-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= , 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-Rspamd-Queue-Id: BD4DB120002 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 3xhg7h94d3u7dmougzic7ney5734ubzz X-HE-Tag: 1703234494-168779 X-HE-Meta: U2FsdGVkX18IE9J0RBDQlAu/VFIJM0x9IuLCeRgfagFL2sKFrV/uBwu3YntzuSIstYa8iFu6xH7CWlByLPYKxvjUwMJnuX+M3w16oHvOydRlk1Ri6Yi1n/Udyuu/PZQSWhQlEdfiGhAyawtfd9GLIw5mu0HPeq3u+CKwx0xIfs2DNBsRcRHcf/2RzSF7Ja2YxdTdc4dtMJ7RLxJwz6mlgzjMAnc0k5q73nHmZcb8QmsuIxtVJ6LL3rWjby+ti2bu5VAvlKebP16l+ZPWmCRZ5+w3mVLzRuoxMZrl6mFUUbv+5X7eJ0K1a2ivENGEgugYVYppqeWgBWSrBFkfS0Jj+J0tPgQ5kq5iafPsvdQXmLZ5Fa9MKOAkB+3GvVGa93kJ8yl8GRIrLYnmhY9IaIG1K2rK1gOz/DRf7oqiouyG9y0u0uyeDG8B5o5jHLwWmI+/slazwsXK/FUbN1xw+Xq2JJxvKfEiInooikZN7AR2OeIOnjybWBtizW2O4mqlIVUvRCiexK9woK7JDOmatTE5BLnXuwudrzBVOkDrOPJIC+LQUfWyWbTPEkrTaYaGHGS/eyVo2yWK8nXY+CpRM0x3a983lbCkyAzVxKzaDsRKCnZ00wunkIaalsA+8QOyq9WjnJhmwGbztMNqToNpr89cZ40gmZ6zGQQNjEKJOmzJipndPMZmsyHSoSxlSNzdOh4saCJtnDP1zEhlvpbGAi0YjSU2pK5gnL0UmlRYSxMHgVVD3E7JKR6ENQRd8TN8TeclvGdPYpfkvau4BxExGdEelEGvhx9HiZ30GeogBdTJvLTDHDH9guM9h9I6e9dpkJUGqmd2p2wbIYnntCp+069bwLHk3U0nUiX455CIBhQdWqCYwI6BYeAq+ZkCg7HJtaj29R3wxT6QPqR/d/ByKc447thlS71GHm8bDP7CRx9A6LlE7RlkBYm9Lh7+/MZP3aH1OqG224zz23Y/9XFdAsE AFh1sBsT /xT8pUniM13787DA5ow/2HWr0wprR6t2qWm7A3jJzqqz1VXmaDamKq13Lo/ND2GK7Jrg5FiY7ltOtgdYnFGCAENXxLURZusKLL53P581b6Ux1FG10yqm05eCkB1kUsQ+FQFR8Mr+CwR5KDXvcWWJjFrjPHoIdB45ch6q4LUHma67dMfsF97g9K5Px3Bm7l1XvnsaUmVnN5fGDjhznu+YDEbAAWvM0q9qEFczIfbEtuZIt+T7ohSgsmjsKO4mwvnxhYpBlyWDhWHiCajR1GoKgndBtkZ46YhUGLcy13K1WoznepiCDWHOEn+6w0e+LxuSQWDB4e68xcd9WvMhKJHd9AL9U/Kpriv94mp+8jF/ssrb/3NHo2w9Hf4nb5qE6M8dx5ruU2mxjvtpWNQkvtHohts6iNT99Q2JuYGS6Eyqohn8rbsCCg3cB9x4z7JA06b0YWPvbgXO1zRZkeXfwbt4Tr6dXn/4zK3gN5Nw/KfoVvGF6rVc3sYa2rXHwgwfrD3jDRavpH2lSLCm0IvEQF2+u0r+c1eY48YM9aZaZeWCgwucNCpqtJewUsAdtug== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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: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 (Zha= oyang 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 w= rote: > > > > > > > > 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 wrot= e: > > > > > > > > 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 w= hen it is > > > > > > > > > > scanned in shrink_inactive_list, while the vfs folio wi= ll do this > > > > > > > > > > immidiatly when it is accessed. These will introduce tw= o affections: > > > > > > > > > > > > > > > > > > > > 1. NR_ACTIVE_FILE is not accurate as expected. > > > > > > > > > > 2. Low reclaiming efficiency caused by dummy nactive fo= lio which should > > > > > > > > > > be kept as earlier as shrink_active_list. > > > > > > > > > > > > > > > > > > > > I would like to suggest mark the folio be accessed in m= inor fault to > > > > > > > > > > solve this situation. > > > > > > > > > > > > > > > > > > This isn't going to be as effective as you imagine. Almo= st all file > > > > > > > > > faults are handled through filemap_map_pages(). So I mus= t ask, what > > > > > > > > > testing have you done with this patch? > > > > > > > > > > > > > > > > > > And while you're gathering data, what effect would this p= atch have on your > > > > > > > > > workloads? > > > > > > > > Thanks for heads-up, I am out of date for readahead mechani= sm. 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 patch > > > > > > > > and provide benchmark data in new patch set. > > > > > > > > > > > > > > Understood. I don't know the history of this, so I'm not sur= e if the > > > > > > > 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 "promot= ed" on > > > > > > the second scan. This RFC would regress memory streaming worklo= ads. > > > > > 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. > > > > > 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 prese= nt 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 help = improve scan efficiency in (3)(4) > > 3. none VM_EXEC mapped pages are dropped as vfs pages do during 3rd sca= n. > > > > (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 > > 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. @@ -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 accessed + * as minor fault + */ + if(folio_mapcount(folio)) + folio_mark_accessed(folio); /* * We found the page, so try async readahead before waiting= for * the lock. > > So it doesn't behave the same way the mainline does for the first case > you listed. (I didn't look at the rest of the cases.)