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 E7457C3DA7A for ; Thu, 22 Dec 2022 19:48:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0484C940009; Thu, 22 Dec 2022 14:48:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F400D940007; Thu, 22 Dec 2022 14:48:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB581940009; Thu, 22 Dec 2022 14:48:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CE026940007 for ; Thu, 22 Dec 2022 14:48:48 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ACE891A0EFE for ; Thu, 22 Dec 2022 19:48:48 +0000 (UTC) X-FDA: 80270979936.11.B5D7687 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf28.hostedemail.com (Postfix) with ESMTP id 049A0C000C for ; Thu, 22 Dec 2022 19:48:46 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kSlZyEuZ; spf=pass (imf28.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 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=1671738527; 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=r2F81c9AgLyck1wSShCjUojXRC7u44cFLH6IR6oWmN4=; b=NcM/czRDgC2GtKG0xyMXypSZ3WdVMuNivxlharzA8VxNzmEO65CI2xgzGv5OhpSIWbvCGa jLewS0FZA/JvGX6SZ4F0EeDRs/diUMbIuair3+UIZwfysGV56fzBXlK1miN9pzXM+MskYF bi3TPtEbUECWXek5amtuf/Z5PsgSxdk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kSlZyEuZ; spf=pass (imf28.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 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=1671738527; a=rsa-sha256; cv=none; b=RJGKH885hPVkef0uyya4mf648ivUV+4X8BZ5z++16ROukcvQLwa1HrHRNCHq2V+58RpFh4 CjBHBIQYLV2rKhinBCTsUVBgrYkH00Rn3DhKdvMZigTjs9fohjIdMJev1AXDoq836OSsvQ 0+0TkYYOoY5/FMYG60tZlv/NJfcQJ+U= Received: by mail-wr1-f53.google.com with SMTP id bs20so589441wrb.3 for ; Thu, 22 Dec 2022 11:48:46 -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=r2F81c9AgLyck1wSShCjUojXRC7u44cFLH6IR6oWmN4=; b=kSlZyEuZcFe3XKq6gnldT7ZyYLU+Awg8l/XPuFUO6xWtYw2ql8CF2LrYCXZh+rLhpa 5AxuhZlgHyNYEFINeAHMf5n203LqWTNZnbPtsuL1cCbkHKpI/jcw7ADkXOCsfPfoyT2N 5Oz1QSJ0EFDUDuFRZQdw4VKokCQwLWCPmIjb76j42aHzWO13v65n6CUhnmHQ/jcj8pVW lI+Y9QO/g+vozwln/Eiq+pDvUEk86SJxIjVd3UUrCrRJdP3RbXSNo3nRqNm3CiDxZ5eO /829JKee1x2sONrCsGazWVX92jRgfQiH3jq76ofawUgUnCgeXLgzC3ERx62TFVQ602hc LkWQ== 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=r2F81c9AgLyck1wSShCjUojXRC7u44cFLH6IR6oWmN4=; b=4G11FWFVVji5b1OSCfzABwaSPoNhGNG3ppM/G2WTW1JqlzOgJui8doOXZ8ZzbFJtc6 nHBBd6EbkQCxbybIFR/7Ob9Tc6Y8nyqZbDsqi0lh4IdYrFVSKhS583lFYK2ZkJiFsOtc CG7kS9dpL1Bdmxfcyo/yB1zIxj0hluFYrmp+DIJvEaUVmMvb4snv+moFPra24cRm/7uM pmo2VdnLbATdxKQOB7z3wg/LvX5+bfo/GQ6gajW3HsA/Bw4ty1zfxgAyIuz7IdCOUm7e qgvN6TBWtW0HYd1W3ftcEJ6Rbnd7+8hzbJshpwbS0kcF2ujvtY1MIeNcDpMgnDBvy5S2 MiVA== X-Gm-Message-State: AFqh2krkL1ZmuhAc1fGivgF2RK+5yTM01N/RpSvQDU6tqWyOQmsW05dg vmwIEVzYAWGBPrk6tj4UJvh7oIBGw/aQwA== X-Google-Smtp-Source: AMrXdXspmFuBlfR7gc2dyZfjSGXzAUYJQsYI7d+BPRPXgeycabrEGMA3kSnSuTF+GM0HYPE8veGWIg== X-Received: by 2002:a5d:61ce:0:b0:242:fd7:285c with SMTP id q14-20020a5d61ce000000b002420fd7285cmr4337447wrv.48.1671738525359; Thu, 22 Dec 2022 11:48:45 -0800 (PST) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id i1-20020adfb641000000b002425787c5easm1349317wre.96.2022.12.22.11.48.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Dec 2022 11:48:44 -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 , Lorenzo Stoakes Subject: [PATCH 4/4] Documentation/mm: Update references to __m[un]lock_page() to *_folio() Date: Thu, 22 Dec 2022 19:48:33 +0000 Message-Id: X-Mailer: git-send-email 2.39.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 049A0C000C X-Stat-Signature: 14rhyxce8qebqgcn1mae4x5rt6jskkk1 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1671738526-931314 X-HE-Meta: U2FsdGVkX1/JiRsSZmr50moimbYvk3PaVS5t4f6lnZRaxkMjxNG0FMPf6W20crbbJeZfcH7YWdvJQwSDZ8tmritfAUMhgHVKqMQD2bv98CGXqwF3gVmvyMYL11/rz0HsJ1mWMk+fKGm2wi1AYYLBWP7kHmDQ/Sib7SeSx1tBi34Nn0ukhYEtFcTIDxu4xzclkOPQy/cpUNewRkyunpmEnc4afbH5icTBIk2gT9kDjfhzC8lrYZzAAhQkXo6YR0bKcX70QDD29GjEG7jYeN8JG2bK9lIO4xYYqS3+InmChXz7608Zl02YEnM2HOmy9VcOp1Jd7yY8CET3iH3xBJ+Yc5Tj3lXGaOK43nbRC5WgKIcMkMhIYfPcSChiIHxMy5O5ARm7zobVLYtVINMGCbgUYX2SQZruhNVS797IbEwEMQjUbta2z/PB/y5nX4G+7VKLDrvkmUR4e6BHMCJS8tCXD7f7k0YGE3SXEzb8FEz62qnICnBWLlzQhySoAM9vDVcR112dgy/pXGWChL77wYiJd5j+esMd+qN/ulrMFaU+tiHHzUuT3pOUaNwHU46zylZlCv8lt+dndF5+mfOvnDS4PXu7Pbuuix3PLmL1wDJxarPhiVX/b4rosAen7ORJhDEf3ReFwLq8E/ikxdpqEww07uwSORYwpLP9J954HE2UUe2QCixXcQskIgWE8RIpPU8nq52StrypITjx1PeEBsOtNKNaaPCfGkeTfkUBvGFSiN/gJunU1NSx7XuHllRyxB1swheePRNauNksbQYJKjb2bH9kVvBEQNA4rZOdx52icpf6orHdIoUz0EQAcazuhlQ5uxl5qLj/EGY5DU7bA+kX0oUV/G2CkRxZ9aNF1cUmqwmsB5+Tt0PJjdRVXdY8nh3uGh8Z+4OR/eba31lga1mr0LWL6bvHOA2A8Ku2guFJvNj+ZxP5M+o9ICCE2vaZhVMJGDFGyq3ls1zUS/wYfG4 oaJZv6EG cEon6TPn2nODrYjSLq+ePfMJoFyBq9QUJTuScV+7Cd8mZrODItveEX6je533xOyWeXiD0mJyFyg3a2ZvYvBuiTaUx6kFWdXBu4aVoG6LE7rc4s2NN49FkbrW4QUxk5Y2dd34LAurvo3tghcLy3d9CU0hEM44lMdCGX7fvpVOwJyCnHnI= 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. Signed-off-by: Lorenzo Stoakes --- Documentation/mm/unevictable-lru.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst index 4a0e158aa9ce..153629e0c100 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 +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 PageMlocked 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 PageUnevictable, 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. 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 -- 2.39.0