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 0E50FC41535 for ; Fri, 22 Dec 2023 06:15:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E7726B0075; Fri, 22 Dec 2023 01:15:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 897C16B0078; Fri, 22 Dec 2023 01:15:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75F406B007E; Fri, 22 Dec 2023 01:15:10 -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 60B7C6B0075 for ; Fri, 22 Dec 2023 01:15:10 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2D897160793 for ; Fri, 22 Dec 2023 06:15:10 +0000 (UTC) X-FDA: 81593441580.29.3486C73 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf15.hostedemail.com (Postfix) with ESMTP id 854F0A001A for ; Fri, 22 Dec 2023 06:15:08 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qKNQhoOu; spf=pass (imf15.hostedemail.com: domain of yuzhao@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703225708; 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=xWaRTLWg3LMWL5DhKaonOO+YqljRMaqWOibiVDR3kcg=; b=1UxzuP2Rh6vutF93uSCQIZV70vUoSvvK/Uzo2LbXf62GWX0y7dvF7DRBvKS6cxXPNjHUjg GNhYlABoohhSHlbBTKr2L5liy8QBJ9P0lhC1bOsqDnhjt9yUXzwWGYjBepdh4eeXA5E7/6 dA5zOQvfmhoFi/JS94SHdGMfDoWT974= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703225708; a=rsa-sha256; cv=none; b=4SOG+8obe+62aVXYvhMl/IE2SvFr1X0OiqTfhUYS5ePFFW8ENaX4r3GDK8qPy0ePk4aDVF Zm63N/YS37eebCYbxe+2dPUB+/B9MQxtQ+ZR9Bq22fpYRhPaaRwl/MydGCh5iwGooDx3iG cU1/sGd6xzgdKLi/56J3LTIyMJUBw7M= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qKNQhoOu; spf=pass (imf15.hostedemail.com: domain of yuzhao@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5534180f0e9so5426a12.1 for ; Thu, 21 Dec 2023 22:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703225707; x=1703830507; 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=xWaRTLWg3LMWL5DhKaonOO+YqljRMaqWOibiVDR3kcg=; b=qKNQhoOu598awzyP+XlP0d2K4pq6RbTviS9WJRti3Yq2xvJkkLSMF4i+1y8ORdccka UwJsfCDkai+nW4WvIWOqVsx4YbnxD4kg0j+jvHZjjWaunQMLKlkxb2EZLBOEfnF4rEaE yDT8vcvmnoYm7upREBKyUtL0vgiIkqQrixpz+IVPrAVDYd0a9KSsixHO/yFCiULvVn7J lt5rfAYuU0h+2osES74EjIADB9TkZ10Uf6WougxAhxMGaBa7V8ij4m44xu7NxhCkrxCa /8Ep3SR5giIaa6ESUHr3I602yzRCOFS8CLJsZxGpXRPesjPc47MmKPr/nBYNcSnVE+Mu Uq4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703225707; x=1703830507; 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=xWaRTLWg3LMWL5DhKaonOO+YqljRMaqWOibiVDR3kcg=; b=dqNgnInOCJ4kQ14XbMSKTnVW/bxqMLzba9wzf6c+q1kiGxL4h8hNjezsu7h8JVWX9d GYDe109wbnlqDb8j9bQEHVBU0xbr1OswDjG/kjgQr4WeTrrXVmYVX9La8jduffAqRitm C+eeWm9+zGIhDjJOJ7zMwjyl9EUd7bMj4WdcftezG8TIYO+YcFbwnT48vi8y5Z3e8ThL UMc6Tlo/eM5rWqeUy/8tsVVad1yWMTvzymNAuCItBG05wbehslKcYZYgm1kjn/4Fz4vr Cmn+AkVjRYHLYWWWPZ8QYKAHMKDZ106aYdVcrsXNYBfOXv9ECOT5C+JXXyDdAvgG0v9x TCgw== X-Gm-Message-State: AOJu0Yz2CQLc0oj+3UelM6J/ttiZmMA9G8Xj8gYDbvuB5NegMjJeBER1 +rMk06nOx9x7Nfougwo5emdNlTXUE4tOromVm6HTPimT6dwc X-Google-Smtp-Source: AGHT+IECN++lj0A1ePVbuyw6vrcleKdovCl0zGxry4CX4mKzgacPTjRdZOt0iOehPlWAxAcsqa7WxixBslnFbYa7ggs= X-Received: by 2002:a50:f611:0:b0:553:faf5:6841 with SMTP id c17-20020a50f611000000b00553faf56841mr44796edn.5.1703225706799; Thu, 21 Dec 2023 22:15:06 -0800 (PST) MIME-Version: 1.0 References: <20231220102948.1963798-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Yu Zhao Date: Thu, 21 Dec 2023 23:14:28 -0700 Message-ID: Subject: Re: [RFC PATCH 1/1] mm: mark folio accessed in minor fault To: Zhaoyang Huang 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-Stat-Signature: 3trj89ftm7baopw4x3q6hrhmc1knxpna X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 854F0A001A X-Rspam-User: X-HE-Tag: 1703225708-774152 X-HE-Meta: U2FsdGVkX1+9CcAmwjP0WzCgRWgYxgBpmyl4nyavHbWZiYhqj3QZO3XDgcxYdCz8TihLG0dKJYz225ga12U7TRWzu/oq0eFLDX5JBlnVSIDurlA4rkygdkbWvMvN7xLLnRSh63dHuTcD2b9azFeW8rV37jZC2sAJtmlQWKaHdUXYJLNECCwRGcX57eXq7+9ZRCFe4LAV5KQnKYYUCisr/ps73vsSPiNXrFVpE8sIP7LvRvTPSvRvvc73e8ZqHPXKTsQ2lOUk6GgKfgIypeW8O6KK2aSc3P+1WpjOorXhcT/rAMu9W6kTVQ8+g0Ye6q9+EStWR4GB3DxPOF00v4zivdNovj42lo8DKv3jvFi1T3zFMhfY2SvqK1Nd//ApJsVEMnrPOGF+LCnR2d3o1bJcil4UpNgRNkzuBB0e7AiiNbtjBjvimjdR2Kj6xvSqG3Nxti/WSbn/I2e5ymsrA0azfw6iha+Sajjq6qVvDtoLcXocZ9eL9wCo7KQoB7ue1f9xDc4k3T+jNUbEZGtvMjfeqygp6CLaAaShQFfhLmLhaaUectTcYm0hYbfiwyj/N7mEqgOqbJrteUQuHKlA2R+4hyI6vQZe+C6Iyjzruae95l/8QWbOQvLRvyhNt+n5TmYBw8yXfXtiPnd4Istx9O27kFKIlh033Rm3qySUyDytD6wZW3UyDXy35VMq+zj5ZrnMQDX6nA+juMyKJB6auaqgoEaEEamVRreiknfEch1rVEJ1QVUMyoCSN5OY9w/48XhkppcUwcJVy9Q46evWPm1LHfgv/38w/Y2rwkDN/+7HYjzV5ZEJwc5i5bSuL22+Nw/WscVDvqpOXSQScG3TEnTJUJy+yX+XRl2ljiu+PmkDOJY9lxFgMrnq0o7zPxQ1XK8yx2Gm033wk/xnOXgVeu199gACCLmMJM/etdrDuvZ6IX8a+LX9wQEJAi3Ga8wJi+Ewxy3FQJ272gVehbk3VCB 6KQ== 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, 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 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 wrot= e: > > > > > > > > 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 d= o this > > > > > > > > immidiatly when it is accessed. These will introduce two af= fections: > > > > > > > > > > > > > > > > 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. Almost a= ll file > > > > > > > faults are handled through filemap_map_pages(). So I must as= k, 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 mechanism. = My goal > > > > > > > > > > It's not a terribly new mechanism ... filemap_map_pages() was add= ed nine > > > > > years ago in 2014 by commit f1820361f83d > > > > > > > > > > > is to have mapped file pages behave like other pages which coul= d 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 sure if= the > > > > > decision to not mark folios as accessed here was intentional or n= ot. > > > > > 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 se= t > > > > 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 mino= r 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? > 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 w= e > > > can distinguish them in advance.