| Message ID | 20231220102948.1963798-1-zhaoyang.huang@unisoc.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel+bounces-6746-ouuuleilei=gmail.com@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp2544203dyi;
Wed, 20 Dec 2023 02:32:46 -0800 (PST)
X-Google-Smtp-Source:
AGHT+IEFd5Nf5wXfKZP1LjBkTD5RGjfCKPlkU6t89rnKxU9pP2a1po4ZNm1XP+SWQHQwpFqBd4Bp
X-Received: by 2002:a17:906:d41:b0:a23:73db:391a with SMTP id
r1-20020a1709060d4100b00a2373db391amr1096651ejh.149.1703068366540;
Wed, 20 Dec 2023 02:32:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1703068366; cv=none;
d=google.com; s=arc-20160816;
b=EMpiQ8MbaYGPBpDpMGLh8udxC6naof8SLfvPveYoWslulHpyC5OjfF3+dznLNsq5s2
mVcQeU3PVzJlIeBWuZ0rdgYQzUWEh2Ip0Pd5V/Ql2r7KUbez432B1ZX0zG/MTTGVv0KM
WCVeomZsECwHPfkqi7x5EVqba2adSFPl9k6oLBc+tmVVR//qveXuEFb25BlqBspLwI3P
BEb8qe6Q3m7iqnO2zK8EM+ZViJgBrRsxzBWoQqM9Ky2+U7cEsC7ooLs18ldlT9dffnFm
qgtHHlVIg69KhCxykJYFtaVgA7kz9551rIkpVLCRioI1OUYPy5isEo5IWfEyL5bowrNM
pLtQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=content-transfer-encoding:mime-version:list-unsubscribe
:list-subscribe:list-id:precedence:message-id:date:subject:to:from;
bh=IcMCJjSuJWg2+1zOkqHn43M0PiRi8RQRNjPEivqGzNY=;
fh=5g6lE+buQy4ZOwE68BhwwYhQDuD3QGYo1sTjLX26BVI=;
b=hLAUbZWDrzpIWto4YGvjMikzsUDA2G2DksiDX1HkPtw+qcBPtcKyUF4r9Zx82/5W6b
RM+xlICeKDc/LJkno+eyMC7f9yFsOcP3528LKb/BVVFHjh2cl/Kc3v6ajv+N0OpORQR+
Kzw8zJtVpsoevLpUoQU7RIZ2cleBTED/09JijJL9+PQ5CZghZm52uJ47/2MuBNanmHDk
HOObiukSkVIPoB/zD16unc+yYzTLp/dBt8KbdPtwSCMsnvY6BC5k+gLmOiV+9N/qietY
J2AJUWKcAWzgQE1gMHeNn4IYIlemySl9OUmLdu7fvtkCkTIQTY4BOonMXTf0q7FlETSD
cO7Q==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of
linux-kernel+bounces-6746-ouuuleilei=gmail.com@vger.kernel.org designates
147.75.80.249 as permitted sender)
smtp.mailfrom="linux-kernel+bounces-6746-ouuuleilei=gmail.com@vger.kernel.org"
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249])
by mx.google.com with ESMTPS id
s22-20020a170906bc5600b00a2363129eb5si2267537ejv.403.2023.12.20.02.32.46
for <ouuuleilei@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 20 Dec 2023 02:32:46 -0800 (PST)
Received-SPF: pass (google.com: domain of
linux-kernel+bounces-6746-ouuuleilei=gmail.com@vger.kernel.org designates
147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of
linux-kernel+bounces-6746-ouuuleilei=gmail.com@vger.kernel.org designates
147.75.80.249 as permitted sender)
smtp.mailfrom="linux-kernel+bounces-6746-ouuuleilei=gmail.com@vger.kernel.org"
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org
[52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 8FF7B1F26D71
for <ouuuleilei@gmail.com>; Wed, 20 Dec 2023 10:31:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 270F921341;
Wed, 20 Dec 2023 10:30:52 +0000 (UTC)
X-Original-To: linux-kernel@vger.kernel.org
Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5B25210F5
for <linux-kernel@vger.kernel.org>; Wed, 20 Dec 2023 10:30:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dmarc=none (p=none dis=none) header.from=unisoc.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=unisoc.com
Received: from dlp.unisoc.com ([10.29.3.86])
by SHSQR01.spreadtrum.com with ESMTP id 3BKATt6H069490;
Wed, 20 Dec 2023 18:29:55 +0800 (+08)
(envelope-from zhaoyang.huang@unisoc.com)
Received: from SHDLP.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7])
by dlp.unisoc.com (SkyGuard) with ESMTPS id 4Sw8mD0818z2QJrHp;
Wed, 20 Dec 2023 18:23:39 +0800 (CST)
Received: from bj03382pcu01.spreadtrum.com (10.0.73.40) by
BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id
15.0.1497.23; Wed, 20 Dec 2023 18:29:53 +0800
From: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox
<willy@infradead.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>,
Zhaoyang Huang <huangzhaoyang@gmail.com>, <steve.kang@unisoc.com>
Subject: [RFC PATCH 1/1] mm: mark folio accessed in minor fault
Date: Wed, 20 Dec 2023 18:29:48 +0800
Message-ID: <20231220102948.1963798-1-zhaoyang.huang@unisoc.com>
X-Mailer: git-send-email 2.25.1
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: SHCAS01.spreadtrum.com (10.0.1.201) To
BJMBX01.spreadtrum.com (10.0.64.7)
X-MAIL: SHSQR01.spreadtrum.com 3BKATt6H069490
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1785796615477815679
X-GMAIL-MSGID: 1785796615477815679
|
| Series |
[RFC,1/1] mm: mark folio accessed in minor fault
|
|
Commit Message
zhaoyang.huang
Dec. 20, 2023, 10:29 a.m. UTC
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> 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. Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> --- mm/filemap.c | 5 +++++ 1 file changed, 5 insertions(+)
Comments
On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > 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. 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 have on your workloads? diff --git a/mm/filemap.c b/mm/filemap.c index 2e6b1daac6cd..8cecf82dcc5a 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3418,6 +3418,7 @@ static struct folio *next_uptodate_folio(struct xa_state *xas, max_idx = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE); if (xas->xa_index >= max_idx) goto unlock; + folio_mark_accessed(folio); return folio; unlock: folio_unlock(folio);
On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > 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. 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 have on your > workloads? Thanks for heads-up, I am out of date for readahead mechanism. My goal 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. > > diff --git a/mm/filemap.c b/mm/filemap.c > index 2e6b1daac6cd..8cecf82dcc5a 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -3418,6 +3418,7 @@ static struct folio *next_uptodate_folio(struct xa_state *xas, > max_idx = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE); > if (xas->xa_index >= max_idx) > goto unlock; > + folio_mark_accessed(folio); > return folio; > unlock: > folio_unlock(folio); >
On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > 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. 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 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 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 sure if the decision to not mark folios as accessed here was intentional or not. I suspect it's entirely unintentional. By the way, rather than inserting an explicit call to folio_set_accessed() in filemap_fault(), change the filemap_get_folio() call to __filemap_get_folio() and add FGP_ACCESSED to the fgp flags.
On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > 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. 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 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 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 sure 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 "promoted" on the second scan. This RFC would regress memory streaming workloads.
On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > 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. 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 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 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 sure 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 "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 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.
On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > 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. 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 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 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 sure 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 "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? > 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.
On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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.
On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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. 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 we > > > can distinguish them in advance.
On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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. > 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 present 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 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 1st scan(shink_folio_list) 2nd access 2nd scan(shrink_active_list) 3rd can(shrink_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) (4) 1st access 2nd access 3rd access 1st scan(shrink_active_list) 2nd scan(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) > 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.
On Thu, Dec 21, 2023 at 11:29 PM 黄朝阳 (Zhaoyang Huang) <zhaoyang.huang@unisoc.com> wrote: > > > On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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. > > > 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 present 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 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 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. 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.)
On Fri, Dec 22, 2023 at 2:45 PM Yu Zhao <yuzhao@google.com> wrote: > > On Thu, Dec 21, 2023 at 11:29 PM 黄朝阳 (Zhaoyang Huang) > <zhaoyang.huang@unisoc.com> wrote: > > > > > > On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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. > > > > > 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 present 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 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 > > 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 = 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.)
On Fri, Dec 22, 2023 at 2:45 PM Yu Zhao <yuzhao@google.com> wrote: > > On Thu, Dec 21, 2023 at 11:29 PM 黄朝阳 (Zhaoyang Huang) > <zhaoyang.huang@unisoc.com> wrote: > > > > > > On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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. > > > > > 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 present 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 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 > > > 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 = 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. > Please find bellow for the stat machine table of updated RFC, where RFC behaves 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(shrink_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 scan(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) RA INA/UNR INA/REF ACT/REF ACT/REF NA > > > > 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.)
On Fri, Dec 22, 2023 at 2:41 AM 黄朝阳 (Zhaoyang Huang) <zhaoyang.huang@unisoc.com> wrote: > > > > On Fri, Dec 22, 2023 at 2:45 PM Yu Zhao <yuzhao@google.com> wrote: > > > > On Thu, Dec 21, 2023 at 11:29 PM 黄朝阳 (Zhaoyang Huang) > > <zhaoyang.huang@unisoc.com> wrote: > > > > > > > > > On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > > > > > > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote: > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote: > > > > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote: > > > > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > > > > > > > > > > > > > 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. 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 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 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 sure 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 "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. > > > > > > > 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 present 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 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 > > > > > 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 = 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. > > > Please find bellow for the stat machine table of updated RFC, where RFC behaves 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(shrink_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 scan(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) > RA INA/UNR INA/REF ACT/REF ACT/REF NA > > > > > > 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.)
I update the patch on v515 as below[1], which calls
mark_page_accessed(mapped_page) in filemap_map_pages and
filemap_fault<in minor fault path> to promote none-single-use pages(by
waiving major fault) earlier than the first scan does now. The patch
is verified on a 2G RAM based android system by the test script, which
loops the following 4 steps[2] for 30 times and measures the numbers
of trace event "mm_filemap_add_to_page_cache/mm_filemap_delete_from_page_cache"
which can be deemed as page cache retention rate(could be thrashing
rate also). In terms of the test result, RFC could save 10% of the
add_to page in each phase and get a better APP start time(decreased
5%) .
[1]
diff --git a/mm/filemap.c b/mm/filemap.c
index 279380c..308e415 100644
+++ b/mm/filemap.c
@@ -3124,6 +3125,7 @@
filemap_invalidate_lock_shared(mapping);
mapping_locked = true;
}
+ mark_page_accessed(page);
} else {
/* No page in the page cache at all */
count_vm_event(PGMAJFAULT);
@@ -3147,7 +3149,7 @@
goto out_retry;
filemap_invalidate_unlock_shared(mapping);
return VM_FAULT_OOM;
}
}
if (!lock_page_maybe_drop_mmap(vmf, page, &fpin))
@@ -3388,8 +3390,10 @@
/* We're about to handle the fault */
if (vmf->address == addr)
ret = VM_FAULT_NOPAGE;
+ if (page_mapcount(page))
+ mark_page_accessed(page);
do_set_pte(vmf, page, addr);
/* no need to invalidate: a not-present page won't be cached */
update_mmu_cache(vma, addr, vmf->pte);
[2]
1. start an APP
2. malloc and mlock 512MB pages
3. restart the APP
4. kill the APP
[3]
v515
RFC
add_to
delete_from add_to
delete_from
1. start an APP 41290
88279 32235 79305
2. malloc and mlock 512MB pages 342103 374396
304310 339048
3. restart the APP 46552
162456 42279 176368
4. kill the APP
On Sat, Dec 23, 2023 at 10:41 AM Yu Zhao <yuzhao@google.com> wrote:
>
> On Fri, Dec 22, 2023 at 2:41 AM 黄朝阳 (Zhaoyang Huang)
> <zhaoyang.huang@unisoc.com> wrote:
> >
> >
> >
> > On Fri, Dec 22, 2023 at 2:45 PM Yu Zhao <yuzhao@google.com> wrote:
> > >
> > > On Thu, Dec 21, 2023 at 11:29 PM 黄朝阳 (Zhaoyang Huang)
> > > <zhaoyang.huang@unisoc.com> wrote:
> > > >
> > > >
> > > > On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
> > > > >
> > > > > On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote:
> > > > > >
> > > > > > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote:
> > > > > > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote:
> > > > > > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> > > > > > > > > > > >
> > > > > > > > > > > > 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. 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 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 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 sure 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 "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.
> > > >
> > > > > 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 present 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 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
> > >
> > > > 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.
I agree with that and get more puzzled. The RFC's goal is that the
more minor faults over the page the sooner it gets promoted as vfs
pages do.
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;
[RFC behaves the same as above]
the second scan of this folio, if the A-bit is set again, moves it to
the active list.
[RFC is NOT against this but just let minor faults promote the page in advance]
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.
>
> > > @@ -3273,6 +3273,12 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
> > > */
> > > folio = 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.
> > >
> > Please find bellow for the stat machine table of updated RFC, where RFC behaves 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(shrink_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 scan(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)
> > RA INA/UNR INA/REF ACT/REF ACT/REF NA
> > > >
> > > > 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.)
diff --git a/mm/filemap.c b/mm/filemap.c index f0a15ce1bd1b..b1ee6ce716c2 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3273,6 +3273,11 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) */ folio = filemap_get_folio(mapping, index); if (likely(!IS_ERR(folio))) { + /* + * try to promote inactive folio here when it is accessed + * as minor fault + */ + folio_mark_accessed(folio); /* * We found the page, so try async readahead before waiting for * the lock.