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 F0B53C61DB3 for ; Thu, 12 Jan 2023 12:40:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25F3F900005; Thu, 12 Jan 2023 07:40:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E775900002; Thu, 12 Jan 2023 07:40:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 013E8900005; Thu, 12 Jan 2023 07:39:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DF80A900002 for ; Thu, 12 Jan 2023 07:39:59 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BB7781A02E0 for ; Thu, 12 Jan 2023 12:39:59 +0000 (UTC) X-FDA: 80346104118.05.7005779 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf20.hostedemail.com (Postfix) with ESMTP id 0DD561C0018 for ; Thu, 12 Jan 2023 12:39:57 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Bj8WAYfm; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673527198; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OIlme2djvGgEExw3u/UZa5uT/mD4cFx99rUFriWDSgQ=; b=wIVI4rZ5no0Be5dCq3ePrsO6S4TNd7vIhw7R7Krt5DmzCx4XVWhJgOw2MKq1CrQA1Lip6A as1a4qfKBqCPDp8E7WyyNJTImTgGJrRkXl4Yg8QWUdq5ImQL8as47CV3VHkXNvKdCC7/qv fg7H/k4xuKuabhNiVFGKnsWuHh0Ifhs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Bj8WAYfm; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673527198; a=rsa-sha256; cv=none; b=ZlFKKcIeYaSqSFBhEj7Oy6tGKWNYg0cclaeXephnsVBPDNlxI3FCqmLb4Ty2b5fLYefchf HJj8GOEWPM+bIHkoCa14OuBFbvh2D6rgiEXXyMZCseIyVzOUFeEVFZrl6E3fsP8pn/F1jv ia39Io+im3eq2ekCsarw4uon+fc06zc= Received: by mail-wm1-f51.google.com with SMTP id ja17so13099758wmb.3 for ; Thu, 12 Jan 2023 04:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=OIlme2djvGgEExw3u/UZa5uT/mD4cFx99rUFriWDSgQ=; b=Bj8WAYfmNP4kC2F8nv3UhSfUx5UZ90gWY74hSp4cxMWGVoIHQnh0Bo3Aef6aY83qfv dorhgyvnMIU6JpVga3F8+FCOQHx/uBvARy+ihQZ0C/8WV74AJPaMzUKyQMOxWObo4xvo yuWHhcjHALhQ/jeFg2dzzQj4pjBd/sL0+b57JLmCguGVxvc7BJU8kLBVRXYU6jzbD8NL pwbSJm0+gllCmV/9EGecEojyVRMShUjU5PT8WaCylGmJ9gvoU4T+QfrUR9Rl5mTF1jdq ETI+dso6dAkU997uRCSVMT8imMqOfh5/VSNUovnsOlDy6iQpzMcK0+DOZaMuRsXwtFZt 7NpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OIlme2djvGgEExw3u/UZa5uT/mD4cFx99rUFriWDSgQ=; b=VUjEO8HR9xHOQ/+UqzOF+8xeTybZI5bT7rRUHSISYX94Mr6LlXtgACsqQN2DpRbTYi wcwiFZ5vC2lJVm+9x3TVO99NeTh1ZEHXqAVNKPYbmz9Uv/4jcMomY7RJ/Y0kcGdRsbvE ZLKDNyiY9jbkhaFE8hEmdLCFbJTfHkKINHYz3Jnw0xHnmI9m4faqdWN6m99xi5B3pWT5 Sx+bSUjuyY5JPE9gicVE265Nl9umAwH4ujre+i0QG4QcqeH723T44+b4J1YyXwnWNevU oPbltKFa/8jSYEMDZRPJ0hY8f4EjUN0GxqPbRPWB+hsdaoBAMCBolkuOAXdt9xkaqpbN z/dw== X-Gm-Message-State: AFqh2krDgfdaM3Yxea31sas3HH6AzTAzmz/XdxiVdBtD6ieuFJSMKYEm m45kXxPMbPUJuwh/WwBY6OJF1/Lo1fc= X-Google-Smtp-Source: AMrXdXsD6QZjC6CFEPGj4WDjoMUtaI4KFAhU9LRm+Y8gJ+XeTafJMWvtnaogTpLw5RcXhi33dckIGg== X-Received: by 2002:a05:600c:1c12:b0:3d3:5841:e8af with SMTP id j18-20020a05600c1c1200b003d35841e8afmr55879654wms.25.1673527196283; Thu, 12 Jan 2023 04:39:56 -0800 (PST) Received: from lucifer.home (host86-164-169-89.range86-164.btcentralplus.com. [86.164.169.89]) by smtp.googlemail.com with ESMTPSA id q1-20020a1ce901000000b003b3307fb98fsm20890797wmc.24.2023.01.12.04.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Jan 2023 04:39:55 -0800 (PST) From: Lorenzo Stoakes To: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org Cc: Matthew Wilcox , Hugh Dickins , Vlastimil Babka , Liam Howlett , William Kucharski , Christian Brauner , Jonathan Corbet , Mike Rapoport , Joel Fernandes , Geert Uytterhoeven , Lorenzo Stoakes Subject: [PATCH v4 5/5] Documentation/mm: Update references to __m[un]lock_page() to *_folio() Date: Thu, 12 Jan 2023 12:39:32 +0000 Message-Id: <898c487169d98a7f09c1c1e57a7dfdc2b3f6bf0f.1673526881.git.lstoakes@gmail.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: ay8k86zqzjmro3y8rtoepzoii4y8x3c3 X-Rspam-User: X-Rspamd-Queue-Id: 0DD561C0018 X-Rspamd-Server: rspam06 X-HE-Tag: 1673527197-714984 X-HE-Meta: U2FsdGVkX197fqQ4riPy5O4Rfx0xDHsKF8tcdDdKIDqkuJIoLlB1xb2Re7bvpHXl1UdJ6P21ZEdd8Qhe48rmGZ+apoqIKA6LRabV7FWxcAZZoi5BAkusyg042+nhvC9h56dx/68WoiIp+kQ7Dg1KfXqfze7Ax5xCBDT2amJAqE7f3TcH8+cy7cfemM1sDxfmw6DNvODnJA+RTjwu24AMezGvaqmsmsLEfjYUQmXsdyFkkTajyk5EPelpbNET9qdE5T9ppPR2GYTwFhQ9gWiWFAZbqNlEjK4xV/kN29pddhhs0m7mwYetvXIFeM6IJLa+j6bMk4ZHoBakCNEJDaWqFcluyFbHz9qKpfc59jIkOwK5AvpFJIgS4L8070gne226IttYyPi/7fyUQOM1o6lcEih21lnDqXidaUoj0XYGzqwQI13VzlwJ+a9A8rpaGNtaV+5x40t+FO6v/Pbq0IC6FXDaadyOLYskUt9MTtu1p5LQajPHral6iR9ZPmXcAFrE+Ccpc51fqJ89lnhnhed9woJkzmNAARmaHwxznpTps4M6+d6/nOmSeGh3EAEmR9hv9KRH8uQYKWL5elyndn93lMWTAxSFbH4C4O5eaPLVYHDG0XsyBxcFiOwj8M7d/WOs4DmpGAWStPI5mBjEh2vDR7pMSMk2Y+h9FxsyBoYNINqkr+Mf4t/vwhz9liwygIlfFY9ZFPSW0AGMv3FnDtXstTTQ94nzlIQYqFpjeDXM38iwpLCEltn+H6wLgrBdA2bq8J/avsUYY6eY4/HrrT4c50Bs0usSDgBXGDAZieo2TY5QphNgkzXoYTi/OP5WpFVW/covIwQc0gTWDhSONMw2KhCQnyru6xUr+y/8m15cKkNd2lcUVbx4cfYgr5RtwzdaWjMILfKEGLSvQMrddo+jQ4/RQVyOrNqxzR7AAlAHRNKK3cr9EW3nAWgR7P8tLW6v4irHPcHZdW2ha9qOFTm 2c45SzC2 Ma82wga8ij/FaaqPK/Y+aWjUB0L4uth+4XWP5ROtkSByw9MuFCrc+9wxsl92aW586fwmCVUUg39A0bz3pQ1bwrZzzU7DYUZyQOCaUj+iRSVihsTHZF6XyGl63s8ODw/r9cHuW7je/slYWFjXM5jAC8KN6l45VRXsgTBhj33aNTOhvKvO7+SG3j+Jqbw== 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: We now pass folios to these functions, so update the documentation accordingly. Additionally, correct the outdated reference to __pagevec_lru_add_fn(), the referenced action occurs in __munlock_folio() directly now, replace reference to lru_cache_add_inactive_or_unevictable() with the modern folio equivalent folio_add_lru_vma() and reference folio flags by the flag name rather than accessor. Signed-off-by: Lorenzo Stoakes Acked-by: Vlastimil Babka --- Documentation/mm/unevictable-lru.rst | 30 ++++++++++++++-------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst index 4a0e158aa9ce..2a90d0721dd9 100644 --- a/Documentation/mm/unevictable-lru.rst +++ b/Documentation/mm/unevictable-lru.rst @@ -308,22 +308,22 @@ do end up getting faulted into this VM_LOCKED VMA, they will be handled in the fault path - which is also how mlock2()'s MLOCK_ONFAULT areas are handled. For each PTE (or PMD) being faulted into a VMA, the page add rmap function -calls mlock_vma_page(), which calls mlock_page() when the VMA is VM_LOCKED +calls mlock_vma_page(), which calls mlock_folio() when the VMA is VM_LOCKED (unless it is a PTE mapping of a part of a transparent huge page). Or when -it is a newly allocated anonymous page, lru_cache_add_inactive_or_unevictable() -calls mlock_new_page() instead: similar to mlock_page(), but can make better +it is a newly allocated anonymous page, folio_add_lru_vma() calls +mlock_new_folio() instead: similar to mlock_folio(), but can make better judgments, since this page is held exclusively and known not to be on LRU yet. -mlock_page() sets PageMlocked immediately, then places the page on the CPU's -mlock pagevec, to batch up the rest of the work to be done under lru_lock by -__mlock_page(). __mlock_page() sets PageUnevictable, initializes mlock_count +mlock_folio() sets PG_mlocked immediately, then places the page on the CPU's +mlock folio batch, to batch up the rest of the work to be done under lru_lock by +__mlock_folio(). __mlock_folio() sets PG_unevictable, initializes mlock_count and moves the page to unevictable state ("the unevictable LRU", but with -mlock_count in place of LRU threading). Or if the page was already PageLRU -and PageUnevictable and PageMlocked, it simply increments the mlock_count. +mlock_count in place of LRU threading). Or if the page was already PG_lru +and PG_unevictable and PG_mlocked, it simply increments the mlock_count. But in practice that may not work ideally: the page may not yet be on an LRU, or it may have been temporarily isolated from LRU. In such cases the mlock_count -field cannot be touched, but will be set to 0 later when __pagevec_lru_add_fn() +field cannot be touched, but will be set to 0 later when __munlock_folio() returns the page to "LRU". Races prohibit mlock_count from being set to 1 then: rather than risk stranding a page indefinitely as unevictable, always err with mlock_count on the low side, so that when munlocked the page will be rescued to @@ -377,8 +377,8 @@ that it is munlock() being performed. munlock_page() uses the mlock pagevec to batch up work to be done under lru_lock by __munlock_page(). __munlock_page() decrements the page's -mlock_count, and when that reaches 0 it clears PageMlocked and clears -PageUnevictable, moving the page from unevictable state to inactive LRU. +mlock_count, and when that reaches 0 it clears PG_mlocked and clears +PG_unevictable, moving the page from unevictable state to inactive LRU. But in practice that may not work ideally: the page may not yet have reached "the unevictable LRU", or it may have been temporarily isolated from it. In @@ -488,8 +488,8 @@ munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED munlock_page() uses the mlock pagevec to batch up work to be done under lru_lock by __munlock_page(). __munlock_page() decrements the page's -mlock_count, and when that reaches 0 it clears PageMlocked and clears -PageUnevictable, moving the page from unevictable state to inactive LRU. +mlock_count, and when that reaches 0 it clears PG_mlocked and clears +PG_unevictable, moving the page from unevictable state to inactive LRU. But in practice that may not work ideally: the page may not yet have reached "the unevictable LRU", or it may have been temporarily isolated from it. In @@ -515,7 +515,7 @@ munlocking by clearing VM_LOCKED from a VMA, before munlocking all the pages present, if one of those pages were unmapped by truncation or hole punch before mlock_pte_range() reached it, it would not be recognized as mlocked by this VMA, and would not be counted out of mlock_count. In this rare case, a page may -still appear as PageMlocked after it has been fully unmapped: and it is left to +still appear as PG_mlocked after it has been fully unmapped: and it is left to release_pages() (or __page_cache_release()) to clear it and update statistics before freeing (this event is counted in /proc/vmstat unevictable_pgs_cleared, which is usually 0). @@ -527,7 +527,7 @@ Page Reclaim in shrink_*_list() vmscan's shrink_active_list() culls any obviously unevictable pages - i.e. !page_evictable(page) pages - diverting those to the unevictable list. However, shrink_active_list() only sees unevictable pages that made it onto the -active/inactive LRU lists. Note that these pages do not have PageUnevictable +active/inactive LRU lists. Note that these pages do not have PG_unevictable set - otherwise they would be on the unevictable list and shrink_active_list() would never see them. -- 2.39.0