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 AE815C25B75 for ; Wed, 15 May 2024 04:47:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E96E46B03C2; Wed, 15 May 2024 00:47:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E20346B03C3; Wed, 15 May 2024 00:47:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C99046B03C4; Wed, 15 May 2024 00:47:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A97CB6B03C2 for ; Wed, 15 May 2024 00:47:52 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 50D0116135D for ; Wed, 15 May 2024 04:47:52 +0000 (UTC) X-FDA: 82119397584.19.FBA3ADC Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 05F86180019 for ; Wed, 15 May 2024 04:47:49 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ClUVt4S2; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715748470; 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=t8yhbp66jHTQyzyxbangMJmJfYfgC0NJRnY0XzF5xlo=; b=qKwT7C8wYuvZvNnmvxiVnl+eKQhpqqco5sUs5SbG3GOtpKBTJ7uUO6bcVzICILYErJwqOh UbMcrHLUpoMkihNDqxPVegqbCKRYqNfDHaGwp3li3gOtxoVEqZdNAlNxcG2wyRxOso8Yhc HG8iLNfZbZDS/UNICJN+lllajIooYaQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ClUVt4S2; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of djwong@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715748470; a=rsa-sha256; cv=none; b=ssL7/OAnPAWWhsuVAXvM6YXc8HHVfSh6zRSwmqRRjXfMJAwOoxEX7UfLkcjapCi85O/j8o T0/l5+Ed9dFRXHUh0iwsfbBH38/kw2qqLeg+gM0XIqaSH28LuT+FB7dWp8MuN7jAsg3wVT q28hlLiLkJcIGfhpt/Y6g5a9l3Zs8Rk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 8DBBECE1392; Wed, 15 May 2024 04:47:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1802C116B1; Wed, 15 May 2024 04:47:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715748465; bh=6fUckgxwLLzf0rniCYbyyFgTJIFLissZPXLhjw/kRvM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ClUVt4S2XoG1SwiZ8pXPXIjAYveaooXldPxrnXX8fl8BP9ME7xDM2D4LdkKzcPp2I IicKZNejEKXU/pC2J/LEjzL8jvoszQ3zvIkZW+s4fTmwGTCBdJ0hCDPn9qwGvAfc+3 YKrnXJJsnhepW/1qjk78OcWlThKEMhcCJZpTD3przuVFOLnz+tYCenn6zCdOGQ0v7R GoSnAwH/OjVZgxc4KodbrBfiS3Mr1hp6Zqsa7RTbkSPMDDYZRgU0BW6y9eCnjXBNJv Nr6GVgIoGxllXR5mLt1mDf5u0IpkZyfAasdLO8ekdLZfHTpE3mjkg4iHoIidcnCqpY 4s3vfdBF4Az0g== Date: Tue, 14 May 2024 21:47:45 -0700 From: "Darrick J. Wong" To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: page-flags.rst Message-ID: <20240515044745.GE360898@frogsfrogsfrogs> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 05F86180019 X-Stat-Signature: pcitcincdxzkhy57ffow7ft5q8r81ayn X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1715748469-732855 X-HE-Meta: U2FsdGVkX1+fcn6yVd6ke3MkF35vvngmkfRY+d/gM9Bv9iAZw76WQNz+JHqLm6h8xc9PnGenb9s7RIZeEDaOPwX49ddm4DPE0IvOKehqLd2YjK0CY9Cx+dO1vagx2kke3YrYKClU2LLgLrWnwqS97LJ2h90BKiaa+JeORCzdVWghaNnJQy5aYIJzjRj4Hs5OTmi3MlVAkk9WcGQhybVaGA+AVqLeyKWiuXno5Qa9DeaMlSy7MfP6QHXN7Ugukdfi3i+RtpO0WKv8pNiVz74BZFaPxKFf4MLWHHSTTwKSF4AKPd0ZLar2pWsZIDX+XVmO8g+NO7La4QneRCieFCzX5I+AzzurddbKPpVzd6p/fihKDpLATTlMF/WpTJ5BGuwDKbgGu8eAD9GmGN/alYXlE06ff5qINhZ6rneW6yPRAGHkfaDmm7OEhqRAHqQDQbYuwD7oiKQTng4gdSmE7+nqfIjmvMzlADhml9JvjrRwGkn9MlHRKQ0LVCcwayQp5qqI3WwzQjv++D3Zu81BzzoxKn5a3q43kccmYLHN2frkIX4CPL3taPluzz04p4SVNstg4hAHLL4T3CboNVxKBq8cjJJWLSyF1WLmOanycMCmeNk92FWFWfrDyF1PDRXpPuEPt/Pvg/ZCgYzfSikojkp7gnJ/yUrCuGZ/5I0oNnDnIpbz58CY9ZTfXsjHT5dFOjfuskXtkbrZkKjTPaGievsFtWZ6J17f3MS9qMB0iskhTFQe7l7PlwfbdT1eZ+qRZr3n5Yg1Aup4X2vsH1sXeVUWutgjOw8mkoTb3G1mZF0nag1Y3s+DIYehYn5gn/X/g6iojIA75CLuUgECZSk3eZ5loLCqV6X8lLKC4Z1qvRfYqTw1h+0vsQIttaj8UME9QCP428950ZF7dLNoh63jv8vIBsYx0p4w1KN932brHRazc5S75jUqKP9FbL7waEVrCaKUPtxiCf647IA19K9u8Kf HLx/nyyr H9KHmMNYY1LzLUITX8bk6I3V6Om92dOWDtizXeRhIfOqwM+8nqDSRBSYdkSQL8GWunSkDbw4xOoQvYyf3dLBi9MB04MG9/PDR9NHElb1baiVlZdfEVh8LMH1HIZRk2MhQqQX3kLzbdvRibnk9ud+UMQDKIF7ImJUyWZqebQcSUmevYUgOTkzncAINMg== 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, May 14, 2024 at 07:35:15PM +0100, Matthew Wilcox wrote: > As encouraged by my lively audience / collaborators, here is the > typos-and-all result of the LSFMM session which just finished. > > Please don't respond to point out the typos; trust that I will fix them. May I bikeshed starting sentences on a new line for better diffability, then? Arbitrary incoherent comments follow: > ========== > Page flags > ========== > > Struct page includes a 'flags' word. Despite its name, various other > things are also stored in this word, including the page's node, zone, > section, and last_cpupid. See include/linux/page-flags-layout.h for > details. > > Locked > ====== > > This flag is per-folio. If you attempt to lock a page, you will lock > the entire folio. The folio lock is used for many purposes. In the page > cache, folios are locked before reads are started and unlocked once the > read has completed. The folio is also locked before writeback starts; > see the writeback flag for more detail. The truncation path takes the > folio lock, and folios are also locked while being inserted into page > tables in order to prevent races between truncation and page fault. If you drop the lock of a pagecache folio and relock it, you have to revalidate mapping and index of the head, right? > ... more detail here please ... > > Writeback > ========= > > Per-folio > This is kind of a lock > We downgrade to it having taken the lock flag > Rekeased after wrut4back completes, but lock flag may be released any time after writeback flag set. Deopends on filesystem whether needs to do more between more between...? /me doesn't understand the sentence. > We can wait for writeback to complete by waiting on this flag > Folio put to tail of LRU for faster reclaim > > Can prevent tearing write is filesystem needs stable folios If the filesystem or the block device (e.g. T10 PI/RAID5) need stable folios. > Truncate will wait for flag to clear > > > Referenced > ========== > > Per-folio flag. At least one page table entry has a accessed bit set for this folio > We set this during scan. Also set during buffered IO. Referenced first time, Accessed second time. > Used during reclaim to determine dispotition (activate, reclaim, etc) > > Uptodate > ======== > > Every byte of the folio contents is at least as new as the contents of disk > implicit write bbarrier > > > Dirty > ===== > Also set during buffered IO. Referenced first time, Accessed second time. > Used during reclaim to determine dispotition (activate, reclaim, etc) > At least one byte of the folio contents is newer than on disk and the writeback flag is not yet set > folios may be both dirty and not uptodate > lazyfree pages can drop the dirty bit > dirty flag clear for file folios when we start writeback > set dirty flag when removed from swapcache > if already dirty, folios can be mapped writable without notifying filesystem > complicated interfaces to set easy to get wrong > redirty_for_writeback > > > > LRU > === > > FOlio has been added to the LRU and is no longer in percpu folio_batch > > > Head > ==== > > This folio is a large folio. It is not set on order-0 folios. Is it not set on the non-head pages as well? > > Waiters > ======= > > Page has waiters, check its waitqueue. > Only used by core code. Don't touch. > > Active > ====== > > On the active LRU list. > Can be set in advance to tell kernel to put it on the right list > > Workingset > ========== > > Set on folios in pagecache once readahead pages actually accessed > Set on LRU pages that were activated have been deactivated, treat refault as thrashing > refault handler also sets it on folios that were hot before reclaimed > used by PSI computation > > Owner_Priv_1 > ============ > > Owner use. If pagecache, fs may use > > Used as Checked flag by many filesystems. > Used as SwapBacked flag by swap code. > > Arch_1 > ====== > > Many different uses depending on architecture. Oftern used as a "dcache clean" or, comfusingly as "dcache dirty". Check with your architecture. > > s390 uses it for basically everything. > > Historicalkly was used on a per page basis. Think we've eliminated all per-page uses now so should only be set on folios. > > Reserved > ======== > > > > Private > ======= > > If pagecache, has fs-private data > > Private_2 > ========= > > If pagecache, has fs aux data > > Mapped_to_disk > ============== > > Has blocks allocated on-disk > > Reclaim > ======= > > To be reclaimed asap > > Swap_backed > =========== > > Page is backed by RAM/swap > > Unevictable > =========== > > Page is "unevictable" > > Mlocked > ======= > > Page is vma mlocked > > Uncached > ======== > > Page has been mapped as uncached > > HWPoison > ======== > > hardware poisoned page. Don't touch I forgot the results of our expedition into why shmem.c checks PageHWPoison so much vs checking for EIO on the file/inode/etc. My hazy recollection is that poisoning a pagecache folio also sets AS_EIO too? If that's true, maybe we should mention that. --D > Young > ===== > > Idle > ==== > > Arch 2 > ====== > > Arch 3 > ====== > > Readahead > ========= > > Aliases with Reclaim as they are usually never set on the same folio, and > if they are the consequences are a minor performance loss. > > Anon_Exclusive > ============== > > Aliases with Mapped_To_Disk as that flag can never be set on anonymous folios. > > Isolated > ======== > > Shared with Reclaim flag, only valid for folios with LRU flag clear. > > Reported > ======== > > Only valid for buddy pages. Used to track pages that are reported > > Has_HWPoisoned > ============== > > Large_Rmappable > =============== > > >