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 30B73C2BD09 for ; Tue, 9 Jul 2024 04:35:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4C2B6B009E; Tue, 9 Jul 2024 00:35:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFA586B00A0; Tue, 9 Jul 2024 00:35:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C1F76B00A1; Tue, 9 Jul 2024 00:35:01 -0400 (EDT) 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 7EBDB6B009E for ; Tue, 9 Jul 2024 00:35:01 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 01AFC416B6 for ; Tue, 9 Jul 2024 04:35:00 +0000 (UTC) X-FDA: 82318949202.08.A447928 Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) by imf23.hostedemail.com (Postfix) with ESMTP id 36EE2140015 for ; Tue, 9 Jul 2024 04:34:59 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.51 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720499684; 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; bh=Q9pKSLhwlTEm+8wiCWId5W4uZXshj+1+rGTAOZQjYl0=; b=aVUroP59MQScz6bh+7Sie1wrkiRynolhaW6rOsZIYOKMgIvVN5JTTEeIiZISlBtWxH8wyX TUxFnaG0asnkXnRh2I8tBHVEg/dOC5655Az8ajuRJA5f8qFdxGSLk2r9JcI7JWcEvet0sa qzPAggeqHf3HnYSJOLj12OCt+WXMhJo= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.51 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720499684; a=rsa-sha256; cv=none; b=vY8xe7/A6clMxZHZsmxkkVbMojGejtz7tt7mgo1PNtURF/4HDyi9+PL+63Bqm6bGSzIifL pV7cU2S+UcQABxtOVx0dy0CQMi8vZVwRukJYtS5LUpfkAVpoMXex6KiN4KGhOt5rNmJX58 gPl1l6nXkgxa8JywDoktR6tZ2ECqtsM= Received: by mail-ua1-f51.google.com with SMTP id a1e0cc1a2514c-81065391658so427581241.3 for ; Mon, 08 Jul 2024 21:34:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720499698; x=1721104498; 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=Q9pKSLhwlTEm+8wiCWId5W4uZXshj+1+rGTAOZQjYl0=; b=kVQ5Uvq+5vSWo18t3EjUr6W/P8vxUC0MzB3q/O5/SP2hHuTYdHs8G5v4rHBprvLghI JAmv52i3WW8opZu9aBPEauU14ytY9TeIrFjX48tdtNDk2Df3D4J314HUhThfKb+31WmF REp/UugFehI5/Hp8LMPOGINudBBDpg/efc7of32p2KbNALF9cHd0mpyVcfBOgGEuKvrC k/8Zh7njbbAycCZ+CyNof5qCMDVAWis3p+ehYxTCMtk0v3bO/wL86D+UneQIIvZR0EFK uK5PhOvsF/2cRbyIUNDlXCj45VCFxZHc5z+xQ/RNs4rDsCJLZc+5t0j8Pr6KChbvGYKJ fKdg== X-Forwarded-Encrypted: i=1; AJvYcCWmJtrobus4J0wZkwK9s//BHTm2TxOE3GWb7GhXilS0WboS7K3IAjrVVklblffE15ezGoZT0ajOyNDnZx5I5b66sws= X-Gm-Message-State: AOJu0YxGOSxwK0V966lMjbzkgbjTZDt1YZwS50h4e1RiviY2KjLqbse8 T3MdjnxXN7LdaF6Qmp6uT1jFGt8a84pQSfdrhNVq83/aQPY8lezKREP116+x2t+uLDJygOq14TY ByhTRYyiyArb3KRO8Xr3gPMe+OMU= X-Google-Smtp-Source: AGHT+IEGtuOs0WLNLxu0K/QwvOYqRoh8N0xrp3vaAAukrFFlb0qHmxF8wtp61DH/zYlXayLImn3mR4XCZg1LzJ+Nf3I= X-Received: by 2002:a05:6102:f88:b0:48f:e7f7:6fe2 with SMTP id ada2fe7eead31-490321d32bfmr1258001137.35.1720499698102; Mon, 08 Jul 2024 21:34:58 -0700 (PDT) MIME-Version: 1.0 References: <20240709042122.631-1-justinjiang@vivo.com> In-Reply-To: <20240709042122.631-1-justinjiang@vivo.com> From: Barry Song Date: Tue, 9 Jul 2024 16:34:46 +1200 Message-ID: Subject: Re: [PATCH v6] mm: shrink skip folio mapped by an exiting process To: Zhiguo Jiang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Matthew Wilcox , opensource.kernel@vivo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 36EE2140015 X-Stat-Signature: f46p5cr8s1doxmd4fusbsmp7rbj53hsu X-HE-Tag: 1720499699-19981 X-HE-Meta: U2FsdGVkX18X/8Q9O5Gpp8rnJ6punHJhjyy8Jc7gv+3MuBNUgIo8YwJphT7xksvGYVYeJQrfvL6GrpXV/JsCJfTGgTtpkudSD4GiQ61Oid7QIaoqKY8Tl2GqorCV0m49368YzaNAoXPUP8G/adhVKHLtchEGeN1oEULjn5Xck6OLRXrAtflC1UtlJg9p/JWxbOMdTq0vv2LawHFvfhcTGRihC9W0MfASash0u5barxZSxnV5u0AQymButO+R9NUszqO777qwyTfoJRc6Lx/s1e7sK1HNZRqipC5DkxcR3fFx1Wang03Kjd5jEJwxuJiJ1V2UtNalDWtmn1/dyK4iAvXpEFNhTvxo6t21UYoK8wPEPPo7kIBvCgo4IHiGvG7d0FCQLjH6QT/egCnn6MuDbgcCPLtUnK+m0EpCGfqezZricRizfsEOm4/fNzciA0oFJ55URyPPGu9lMEjGRCfXvqkUCJ4ANGcCBLfMOig+VgRCVcX+tbq5S4jzs6ZOVS06TCH3HJCeIinScv4m7rTJQ8dLqwfSwGDN3bXsOrjSZycvcexiMTFBV9NOmMu5b6O+EYD1QfSUZST//hQMcKD+JVJeyxQyM3rWudlpgM/IzdbCCpfukjzZqohx7WseLMnv0cazSnkzWY8pRAcZn/bdupl4nZeIRfnW2Hudkyiv6IkFe96xjBnVJ8o98Yajt+36Y8TP3LNT/t2KXNyOqFnL7f3697Ob6YB2JeCwHWiiQfIvAcjTsA7FuJUGfArcz64mbmsY4quYDPKi7pAJIGiwEzN+CR3Hspi/qDxRxuYy5uXnNV5oHW5fzyBnXHtM85HluJgtDL8WqtXEV9uFuDhuAsqA8uq/YqKaJwFMVlE1Pldx4tMaiu1ATgBqZa5UWlLJ5HEN2CzM1jZ62qhWt5jnlgIyKry4MYOJu9dbVs+Ly/XLsH6bSXZfvwdZLoIlCD4/u8TJj0DWbZQiJg/WvTu 00EljZ+j wi53cbUKglWoAvbDv4C6rsWJFx3UBDw4SJQb3k73ak0McN5i4pgi4Ke//aw62x8y0OY4vlH+0Zn2IkkIcfJSlTLsKxv1xMcEX9vexRStEZgBOFPteD9qSb5q8qP1c8vfiOSg/WRSWZH7STOybjL2X7TsSxPG2FlKwA/73pLS8h2rZcymfvBORLRnIFSDw3oXwYwckn1XD1AdHeB1M6aVC+W2M2lsKDxTYRve3zXf0j+5auY9RvD5cvHR+r/zCt9eC27qh2x0y9OSUfr7ys8cguhSlvldn+bSqTKQFjGL/cPpZNzqruZRSxIekLj/wR0XR5n/UqCrpeiDDpsq1mw0s5quFz5ydztIDJa6RDmYLC9VYP47ptSei7Z/PLRUqyneZnjPbp0Fl/1Plk3hODzB9BbKxESM2qEnEzKq7cKJmAIEwlgBMrYGyGjeM+Kn1LNcXE3NqAoem3fMNZ8QI9vDIyr2QIqgmvueYMz1MLO94IsvUcqGdxpezQdMQqpRj3XWDz6Yy 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 Tue, Jul 9, 2024 at 4:21=E2=80=AFPM Zhiguo Jiang = wrote: > > The releasing process of the non-shared anonymous folio mapped solely by > an exiting process may go through two flows: 1) the anonymous folio is > firstly is swaped-out into swapspace and transformed into a swp_entry > in shrink_folio_list; 2) then the swp_entry is released in the process > exiting flow. This will result in the high cpu load of releasing a > non-shared anonymous folio mapped solely by an exiting process. > > When the low system memory and the exiting process exist at the same > time, it will be likely to happen, because the non-shared anonymous > folio mapped solely by an exiting process may be reclaimed by > shrink_folio_list. > > This patch is that shrink skips the non-shared anonymous folio solely > mapped by an exting process and this folio is only released directly in > the process exiting flow, which will save swap-out time and alleviate > the load of the process exiting. > > Signed-off-by: Zhiguo Jiang LGTM, Acked-by: Barry Song > --- > > Change log: > v5->v6: > 1.Move folio_likely_mapped_shared() under the PTL. > 2.Add check_stable_address_space() to replace MMF_OOM_SKIP. > 3.Remove folio_test_anon(folio). > v4->v5: > 1.Further modify to skip non-shared anonymous folio only. > 2.Update comments for pra->referenced =3D -1. > v3->v4: > 1.Modify to skip only the non-shared anonymous folio mapped solely > by an exiting process. > v2->v3: > Nothing. > v1->v2: > 1.The VM_EXITING added in v1 patch is removed, because it will fail > to compile in 32-bit system. > > > Comments from participants and my responses: > [v5->v6]: > 1.David Hildenbrand > I'm currently working on moving all folio_likely_mapped_shared() under > the PTL, where we are then sure that the folio is actually mapped by > this process (e.g., no concurrent unmapping poisslbe). Can we do the > same here directly? > --> > You are right. we might use page_vma_mapped_walk_done() to bail out. > (Barry Song) > > 2.Barry Song > By the way, I am not convinced that using test_bit(MMF_OOM_SKIP, > &vma->vm_mm->flags) is correct (I think it is wrong). And exit_mmap() > automatically has MMF_OOM_SKIP. What is the purpose of this check? > Is there a better way to determine if a process is an OOM target? > What about check_stable_address_space() ? > --> > Sorry, I overlook the situation with if (is_global_init(p)), > MMF_OOM_SKIP is indeed not suitable. It seems feasible for > check_stable_address_space() replacing MMF_OOM_SKIP. > check_stable_address_space() can indicate oom kill, and > !atomic_read(&vma->vm_mm->mm_users) can indicate the normal > process exiting. > > I also think we actually can remove "folio_test_anon(folio)". > --> > Yes, update in patch v6. > > [v4->v5]: > 1.Barry Song > I don't think this is correct. folio_likely_mapped_shared() is almost > "correct" but not always. > Please explain why you set pra->referenced =3D -1. Please address all > comments before you send a new version. > --> > Update in patch v5. > > 2.Matthew Wilcox > How is the file folio similar? File folios are never written to swap, > and they'll be written back from the page cache whenever the filesystem > decides it's a good time to do so. > --> > What do you mean is that the file folio will not have any relevant > identifier left in memory after it is reclamed in the shrink flow, > and it will not be released again during an exiting process? If that's > the case, I think we only need the anon folio is skipped here. > > [v3->v4]: > 1.Barry Song > This is clearly version 3, as you previously sent version 2, correct? > --> > Yes. > > Could you please describe the specific impact on users, including user > experience and power consumption? How serious is this problem? > --> > At present, I do not have a suitable method to accurately measure the > optimization benefit datas of this modifications, but I believe it > theoretically has some benefits. > Launching large memory app (for example, starting the camera) in multiple > backend scenes may result in the high cpu load of the exiting processes. > > Applications? > --> > Yes, when system is low memory, it more likely to occur. > > I'm not completely convinced this patch is correct, but it appears to be > heading in the right direction. Therefore, I expect to see new versions > rather than it being dead. > You changed the file mode to 755, which is incorrect. > --> > Solved. > > Why use -1? Is this meant to simulate lock contention to keep the folio > without activating it? Please do have some comments to explain why. > I'm not convinced this change is appropriate for shared folios. It seems > more suitable for exclusive folios used solely by the exiting process. > --> > The skiped folios are FOLIOREF_KEEP and added into inactive lru, beacase > the folios will be freed soon in the exiting process flow. > Yes, the shared folios can not be simply skipped. I have made relevant > modifications in patch v4 and please help to further review. > https://lore.kernel.org/linux-mm/20240708031517.856-1-justinjiang@vivo.co= m/ > > 2.David Hildenbrand > but what if it is shared among multiple processes and only one of them > is exiting? > --> > Modify to skip only the non-shared anonymous folio mapped solely > by an exiting process in next version v4. > > [v2->v3:] > Nothing. > > [v1->v2]: > 1.Matthew Wilcox > What testing have you done of this patch? How often does it happen? > Are there particular workloads that benefit from this? (I'm not sure > what "mutil backed-applications" are?) > And I do mean specifically of this patch, because to my eyes it > shouldn't even compile. Except on 32-bit where it'll say "warning: > integer constant out of range". > --> > Yes, I have tested. When the low system memory and the exiting process > exist at the same time, it will happen. This modification can alleviate > the load of the exiting process. > "mutil backed-applications" means that there are a large number of > the backend applications in the system. > The VM_EXITING added in v1 patch is removed, because it will fail > to compile in 32-bit system. > > mm/rmap.c | 14 ++++++++++++++ > mm/vmscan.c | 7 ++++++- > 2 files changed, 20 insertions(+), 1 deletion(-) > > diff --git a/mm/rmap.c b/mm/rmap.c > index 88156deb46a6..d8ecb918e59e 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -877,6 +877,20 @@ static bool folio_referenced_one(struct folio *folio= , > continue; > } > > + /* > + * Skip the non-shared swapbacked folio mapped solely by > + * the exiting or OOM-reaped process. This avoids redunda= nt > + * swap-out followed by an immediate unmap. > + */ > + if ((!atomic_read(&vma->vm_mm->mm_users) || > + check_stable_address_space(vma->vm_mm)) && > + folio_test_swapbacked(folio) && > + !folio_likely_mapped_shared(folio)) { > + pra->referenced =3D -1; > + page_vma_mapped_walk_done(&pvmw); > + return false; > + } > + > if (pvmw.pte) { > if (lru_gen_enabled() && > pte_young(ptep_get(pvmw.pte))) { > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 80f9a486cf27..1d5f78a3dbeb 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -863,7 +863,12 @@ static enum folio_references folio_check_references(= struct folio *folio, > if (vm_flags & VM_LOCKED) > return FOLIOREF_ACTIVATE; > > - /* rmap lock contention: rotate */ > + /* > + * There are two cases to consider. > + * 1) Rmap lock contention: rotate. > + * 2) Skip the non-shared swapbacked folio mapped solely by > + * the exiting or OOM-reaped process. > + */ > if (referenced_ptes =3D=3D -1) > return FOLIOREF_KEEP; > > -- > 2.39.0 >