From: "Darrick J. Wong" <djwong@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: page-flags.rst
Date: Tue, 14 May 2024 21:47:45 -0700 [thread overview]
Message-ID: <20240515044745.GE360898@frogsfrogsfrogs> (raw)
In-Reply-To: <ZkOu4yXP-sGGtwc4@casper.infradead.org>
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
> ===============
>
>
>
next prev parent reply other threads:[~2024-05-15 4:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 18:35 page-flags.rst Matthew Wilcox
2024-05-15 4:47 ` Darrick J. Wong [this message]
2024-05-16 15:33 ` page-flags.rst Sidhartha Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240515044745.GE360898@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox