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 72120C004D4 for ; Thu, 19 Jan 2023 10:35:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A9AE6B0072; Thu, 19 Jan 2023 05:35:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0598A6B0073; Thu, 19 Jan 2023 05:35:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E634D6B0074; Thu, 19 Jan 2023 05:35:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D71D36B0072 for ; Thu, 19 Jan 2023 05:35:28 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 98C49C03EE for ; Thu, 19 Jan 2023 10:35:28 +0000 (UTC) X-FDA: 80371191936.01.7F710A7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf24.hostedemail.com (Postfix) with ESMTP id 015A7180010 for ; Thu, 19 Jan 2023 10:35:26 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fyCdvJJ1; spf=pass (imf24.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674124527; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hK5mPMd4jGbT5IMDvoXrqvNt37HUysV7kxqiFWkmf/A=; b=7vIpr+kbGtednHdN+ZtHCft4RsAOXPDBbGTcEb1H9XgvHJrYhxG2qxJPEpMPyyTulTUV1H ZKS0MQS5w1TmxnPoo4MrXaZfV4zKAK3SRIqBNX2mFriX1W6co9fzR6Q/hxkLpLAuHOrk+d XUWwm+Em10OjBi5pYVRfvXpFRwBHEYA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fyCdvJJ1; spf=pass (imf24.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674124527; a=rsa-sha256; cv=none; b=4kiPdTuFihxpl/75bBbE38HDptEeJx6P4wQtpe9S83Ps+QEJ0iYt6zWmzztKM4lFYJIg6b b7x6oKIrisGVET5kD3Fz9cG3baVdItBP76FZnQI74OeU7DXWih40DgfAdnDTJybpJFeT3t KNN19pDZzgYkAiesFj4Gx/iG47Vyt/8= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EB8E461204; Thu, 19 Jan 2023 10:35:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A84BC433D2; Thu, 19 Jan 2023 10:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674124525; bh=pWk6gP3R8p/6NkVX0AQ2Im46DSAJU0jW04M1LtDG+aE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fyCdvJJ16i3RllnTuTxGftxb4J2mYHeaajnn+jv7SqjC/SQyJ/C73O3oApAo8tMY5 nZidOWXcgOPZbvgAHUFRIIcNLl+mWIfwhJ0R3SeqUE3Pcq/aBHZil8TQmKZ7NkIS1T 5TUmr15Yik5BQ8LsgHSGUHo0/qHdOzIJ7kXsR+fKKBcWCCIKEXZBeUxeJgC4OIZ07f v8BMuaoVqjMVXGyTYBLTF33cCKRH5mluP/4yBJ6nsRAjGtwS5uXgIzyfut1ZSBm6CY 7Ks9UNUl3IN5Hfc3mUHkl1qB69sZybZi1gwlGcrlvfzBun+OGnfY+aeA7003UsQ8B8 uYq4tFWA/N3cg== Date: Thu, 19 Jan 2023 12:35:14 +0200 From: Mike Rapoport To: "Matthew Wilcox (Oracle)" Cc: linux-mm@kvack.org, Andrew Morton Subject: Re: [PATCH 1/4] mm: Remove page_evictable() Message-ID: References: <20230116192827.2146732-1-willy@infradead.org> <20230116192827.2146732-2-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230116192827.2146732-2-willy@infradead.org> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 015A7180010 X-Rspam-User: X-Stat-Signature: ahxshqb7j8m4asdmjsmogodhjh4xinzt X-HE-Tag: 1674124526-997454 X-HE-Meta: U2FsdGVkX1/cCZJ0SF/JYgbT8EfLQojBM6cEI7A8gTdJv2ibIXqqQMoJiHiBlLP32hGqJL0pLgfWTSe0aQA4K7BSBRAYZbRt3yyboz6zRLFVPnCAAx5wFNkGHRQTRmbVyPP53/rSY8kGXdKC7vXoLUxbesligHohy/tycWxIEc/q+clDZf4cpZlSnBbEYFuGqtX0rTX50X8R3mKgU42/Obv9ZPoa0KwYIoHkqcPf5fsPFgk3roKl8aNqTn8Rq678QLhHLcA6Dw96bqDvhuR3a0FemcuIRK80utx+j3w3R27lDoCD/3kW2hIArzBNZImCelh55khFPNUQXu4fYqmhMGRNIJe/lJ68M6Vj7yyI70XBJG0JTzXGYTV59xwcqdKvyqPYJESFV3mBhGC1FxfCaajinPiuBDqd3dRU55HDCVTw3DdqYMwd4XopESVeic1KXcgIkZy011sgQFnUi0fV5yuMUufzzcZQu5GO/q3b2rB+bJXqZDG6XW0GZmPQO8nT0fVswB9zrbL/NEX+vrQa2Je3KDyUrp3InoCAtRZGaL7Tyr2KvM20BF1D2z2cBWqop2O4DKG8WRgL1KwA3xikCTqPEfnMzY/lxZsPo8AgX0jldNOQceMCczDpwtHp3H2GgQJrXHuMWeW2d8MQo3Nj6IzPt/qX4UlG+diujcG0vjldnQZX7owtU2gsXgvrNePZGgZHcD6uahQ5ZESFRxOjtKzdFCHXc47kKsFT0nv2OK1HwlBsXOp4fQ1L1Yr41jcfYTiP+BbC5QYwhjSRN5tcKkRtjHC4WrnB/au/esAHJnADsntVSlZRtTRrlx2OExgLoN5/fZsvzvf/wKjgvsmUwoOiKDhNr7pq8g1EHz3Cii30HWDAkmfI4lHHyU322PZb2kgHaZGFhIJEAgg9R34chlUK4PUgjf+ECFsOSpOnCbm0ZZa/6ebZXQoPL7o17bN+E5847waoL7kAjr/1/NM KIwJWSia 1razFrc5PN56bf4057m84hnx93IfqbX5lY2zuTxlug6xV9gAZFG8J2KAmyv4A1P8VIwoYpZIehOgBKgI= 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: On Mon, Jan 16, 2023 at 07:28:24PM +0000, Matthew Wilcox (Oracle) wrote: > This function now has no users. Also update the unevictable-lru > documentation to discuss folios instead of pages (mostly). Heh, it's ~30 out of ~180 ;-) It looks to me that we have more places where unevictable-lru documentation should use folios rather than pages. > Signed-off-by: Matthew Wilcox (Oracle) > --- > Documentation/mm/unevictable-lru.rst | 89 ++++++++++++++-------------- > mm/internal.h | 11 ---- > 2 files changed, 46 insertions(+), 54 deletions(-) > > diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst > index 2a90d0721dd9..1972d37d97cf 100644 > --- a/Documentation/mm/unevictable-lru.rst > +++ b/Documentation/mm/unevictable-lru.rst > @@ -12,7 +12,7 @@ Introduction > > This document describes the Linux memory manager's "Unevictable LRU" > infrastructure and the use of this to manage several types of "unevictable" > -pages. > +folios. > > The document attempts to provide the overall rationale behind this mechanism > and the rationale for some of the design decisions that drove the > @@ -27,8 +27,8 @@ The Unevictable LRU > =================== > > The Unevictable LRU facility adds an additional LRU list to track unevictable > -pages and to hide these pages from vmscan. This mechanism is based on a patch > -by Larry Woodman of Red Hat to address several scalability problems with page > +folios and to hide these folios from vmscan. This mechanism is based on a patch > +by Larry Woodman of Red Hat to address several scalability problems with folio > reclaim in Linux. The problems have been observed at customer sites on large > memory x86_64 systems. > > @@ -52,40 +52,41 @@ The infrastructure may also be able to handle other conditions that make pages > unevictable, either by definition or by circumstance, in the future. > > > -The Unevictable LRU Page List > ------------------------------ > +The Unevictable LRU Folio List > +------------------------------ > > -The Unevictable LRU page list is a lie. It was never an LRU-ordered list, but a > -companion to the LRU-ordered anonymous and file, active and inactive page lists; > -and now it is not even a page list. But following familiar convention, here in > -this document and in the source, we often imagine it as a fifth LRU page list. > +The Unevictable LRU folio list is a lie. It was never an LRU-ordered > +list, but a companion to the LRU-ordered anonymous and file, active and > +inactive folio lists; and now it is not even a folio list. But following > +familiar convention, here in this document and in the source, we often > +imagine it as a fifth LRU folio list. > > The Unevictable LRU infrastructure consists of an additional, per-node, LRU list > -called the "unevictable" list and an associated page flag, PG_unevictable, to > -indicate that the page is being managed on the unevictable list. > +called the "unevictable" list and an associated folio flag, PG_unevictable, to > +indicate that the folio is being managed on the unevictable list. > > The PG_unevictable flag is analogous to, and mutually exclusive with, the > -PG_active flag in that it indicates on which LRU list a page resides when > +PG_active flag in that it indicates on which LRU list a folio resides when > PG_lru is set. > > -The Unevictable LRU infrastructure maintains unevictable pages as if they were > +The Unevictable LRU infrastructure maintains unevictable folios as if they were > on an additional LRU list for a few reasons: > > - (1) We get to "treat unevictable pages just like we treat other pages in the > + (1) We get to "treat unevictable folios just like we treat other folios in the > system - which means we get to use the same code to manipulate them, the > same code to isolate them (for migrate, etc.), the same code to keep track > of the statistics, etc..." [Rik van Riel] > > - (2) We want to be able to migrate unevictable pages between nodes for memory > + (2) We want to be able to migrate unevictable folios between nodes for memory > defragmentation, workload management and memory hotplug. The Linux kernel > - can only migrate pages that it can successfully isolate from the LRU > + can only migrate folios that it can successfully isolate from the LRU > lists (or "Movable" pages: outside of consideration here). If we were to > - maintain pages elsewhere than on an LRU-like list, where they can be > - detected by isolate_lru_page(), we would prevent their migration. > + maintain folios elsewhere than on an LRU-like list, where they can be > + detected by folio_isolate_lru(), we would prevent their migration. > > -The unevictable list does not differentiate between file-backed and anonymous, > -swap-backed pages. This differentiation is only important while the pages are, > -in fact, evictable. > +The unevictable list does not differentiate between file-backed and > +anonymous, swap-backed folios. This differentiation is only important > +while the folios are, in fact, evictable. > > The unevictable list benefits from the "arrayification" of the per-node LRU > lists and statistics originally proposed and posted by Christoph Lameter. > @@ -158,7 +159,7 @@ These are currently used in three places in the kernel: > Detecting Unevictable Pages > --------------------------- > > -The function page_evictable() in mm/internal.h determines whether a page is > +The function folio_evictable() in mm/internal.h determines whether a folio is > evictable or not using the query function outlined above [see section > :ref:`Marking address spaces unevictable `] > to check the AS_UNEVICTABLE flag. > @@ -167,7 +168,7 @@ For address spaces that are so marked after being populated (as SHM regions > might be), the lock action (e.g. SHM_LOCK) can be lazy, and need not populate > the page tables for the region as does, for example, mlock(), nor need it make > any special effort to push any pages in the SHM_LOCK'd area to the unevictable > -list. Instead, vmscan will do this if and when it encounters the pages during > +list. Instead, vmscan will do this if and when it encounters the folios during > a reclamation scan. > > On an unlock action (such as SHM_UNLOCK), the unlocker (e.g. shmctl()) must scan > @@ -176,41 +177,43 @@ condition is keeping them unevictable. If an unevictable region is destroyed, > the pages are also "rescued" from the unevictable list in the process of > freeing them. > > -page_evictable() also checks for mlocked pages by testing an additional page > -flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is > -faulted into a VM_LOCKED VMA, or found in a VMA being VM_LOCKED. > +folio_evictable() also checks for mlocked folios by calling > +folio_test_mlocked(), which is set when a folio is faulted into a > +VM_LOCKED VMA, or found in a VMA being VM_LOCKED. > > > -Vmscan's Handling of Unevictable Pages > +Vmscan's Handling of Unevictable Folios > -------------------------------------- > > -If unevictable pages are culled in the fault path, or moved to the unevictable > -list at mlock() or mmap() time, vmscan will not encounter the pages until they > +If unevictable folios are culled in the fault path, or moved to the unevictable > +list at mlock() or mmap() time, vmscan will not encounter the folios until they > have become evictable again (via munlock() for example) and have been "rescued" > from the unevictable list. However, there may be situations where we decide, > -for the sake of expediency, to leave an unevictable page on one of the regular > +for the sake of expediency, to leave an unevictable folio on one of the regular > active/inactive LRU lists for vmscan to deal with. vmscan checks for such > -pages in all of the shrink_{active|inactive|page}_list() functions and will > -"cull" such pages that it encounters: that is, it diverts those pages to the > +folios in all of the shrink_{active|inactive|page}_list() functions and will > +"cull" such folios that it encounters: that is, it diverts those folios to the > unevictable list for the memory cgroup and node being scanned. > > -There may be situations where a page is mapped into a VM_LOCKED VMA, but the > -page is not marked as PG_mlocked. Such pages will make it all the way to > -shrink_active_list() or shrink_page_list() where they will be detected when > -vmscan walks the reverse map in folio_referenced() or try_to_unmap(). The page > -is culled to the unevictable list when it is released by the shrinker. > +There may be situations where a folio is mapped into a VM_LOCKED VMA, > +but the folio does not have the mlocked flag set. Such folios will make > +it all the way to shrink_active_list() or shrink_page_list() where they > +will be detected when vmscan walks the reverse map in folio_referenced() > +or try_to_unmap(). The folio is culled to the unevictable list when it > +is released by the shrinker. > > -To "cull" an unevictable page, vmscan simply puts the page back on the LRU list > -using putback_lru_page() - the inverse operation to isolate_lru_page() - after > -dropping the page lock. Because the condition which makes the page unevictable > -may change once the page is unlocked, __pagevec_lru_add_fn() will recheck the > -unevictable state of a page before placing it on the unevictable list. > +To "cull" an unevictable folio, vmscan simply puts the folio back on > +the LRU list using folio_putback_lru() - the inverse operation to > +folio_isolate_lru() - after dropping the folio lock. Because the > +condition which makes the folio unevictable may change once the folio > +is unlocked, __pagevec_lru_add_fn() will recheck the unevictable state > +of a folio before placing it on the unevictable list. > > > MLOCKED Pages > ============= > > -The unevictable page list is also useful for mlock(), in addition to ramfs and > +The unevictable folio list is also useful for mlock(), in addition to ramfs and > SYSV SHM. Note that mlock() is only available in CONFIG_MMU=y situations; in > NOMMU situations, all mappings are effectively mlocked. > > diff --git a/mm/internal.h b/mm/internal.h > index 2d09a7a0600a..74bc1fe45711 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -159,17 +159,6 @@ static inline bool folio_evictable(struct folio *folio) > return ret; > } > > -static inline bool page_evictable(struct page *page) > -{ > - bool ret; > - > - /* Prevent address_space of inode and swap cache from being freed */ > - rcu_read_lock(); > - ret = !mapping_unevictable(page_mapping(page)) && !PageMlocked(page); > - rcu_read_unlock(); > - return ret; > -} > - > /* > * Turn a non-refcounted page (->_refcount == 0) into refcounted with > * a count of one. > -- > 2.35.1 > > -- Sincerely yours, Mike.