From: Matthew Wilcox <willy@infradead.org>
To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Cc: linux-btrfs@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: State of removing page->index
Date: Tue, 23 Jul 2024 04:12:01 +0100 [thread overview]
Message-ID: <Zp8fgUSIBGQ1TN0D@casper.infradead.org> (raw)
My project for the next few weeks is removing page->index.
The last patch in the series is mostly:
+++ b/include/linux/mm_types.h
@@ -103,7 +103,7 @@ struct page {
/* See page-flags.h for PAGE_MAPPING_FLAGS */
struct address_space *mapping;
union {
- pgoff_t index; /* Our offset within map
ping. */
+ pgoff_t __folio_index; /* Our offset wi
thin mapping. */
unsigned long share; /* share count for fsdax */
};
/**
This is a stepping stone to shrinking struct page by half (64 bytes down
to 32 bytes) [1] and allocating struct folio separately from struct page.
It's currently 15 patches:
bootmem: Stop using page->index
mm: Constify page_address_in_vma()
mm: Convert page_to_pgoff() to page_pgoff()
mm: Mass constification of folio/page pointers
fs: Turn page_offset() into a wrapper around folio_pos()
fs: Remove page_mkwrite_check_truncate()
mm: Remove references to page->index in huge_memory.c
mm: Use page->private instead of page->index in percpu
perf: Remove setting of page->index and ->mapping
dax: Remove access to page->index
null_blk: Remove accesses to page->index
watch_queue: Use page->private instead of page->index
isofs: Partially convert zisofs_read_folio to use a folio
dax: Use folios more widely within DAX
mm: Rename page->index to page->__folio_index
I haven't pushed the git tree because the build bots will choke on
the following files which still use page->index:
drivers/hwtracing/intel_th/msu.c
drivers/net/ethernet/sun/niu.c
drivers/staging/fbtft/fbtft-core.c
drivers/video/fbdev/core/fb_defio.c
fs/btrfs/compression.c
fs/btrfs/extent_io.c
fs/btrfs/file.c
fs/btrfs/super.c
fs/ceph/addr.c
fs/ceph/dir.c
fs/ceph/inode.c
fs/crypto/crypto.c
fs/ecryptfs/crypto.c
fs/ecryptfs/mmap.c
fs/ecryptfs/read_write.c
fs/erofs/data.c
fs/f2fs/checkpoint.c
fs/f2fs/compress.c
fs/f2fs/data.c
fs/f2fs/dir.c
fs/f2fs/file.c
fs/f2fs/inline.c
fs/f2fs/inode.c
fs/f2fs/node.c
fs/f2fs/segment.c
fs/f2fs/super.c
fs/fuse/file.c
fs/jffs2/file.c
fs/jfs/jfs_metapage.c
fs/ntfs3/frecord.c
fs/ocfs2/alloc.c
fs/ocfs2/aops.c
fs/ocfs2/mmap.c
fs/reiserfs/file.c
fs/reiserfs/inode.c
fs/smb/client/smb2ops.c
fs/squashfs/file.c
fs/squashfs/page_actor.c
fs/ufs/dir.c
mm/zsmalloc.c
Some of these will be fixed with scheduled pull requests (jfs), or are
improved (and maybe solved) by other pending series (ufs, ecryptfs,
jffs2, zsmalloc).
Expect to see a few patches from me over the next few weeks that seem
random; there is a destination in mind, and if everything lines up,
we might be able to get to it by the next merge window. Probably
something will miss landing in v6.12 and it'll be the v6.13 release
before page->index goes away entirely.
I believe I have someone lined up to help with ocfs2. If anyone wants to
help with the remaining filesystems (btrfs & f2fs in particular!), let
me know. I'm honestly tempted to mark reiserfs BROKEN at this point.
The diffstat of what I currently have looks like this:
arch/x86/mm/init_64.c | 9 +++----
drivers/block/null_blk/main.c | 8 +++---
drivers/dax/device.c | 9 +++----
fs/ceph/addr.c | 11 ++++----
fs/dax.c | 53 ++++++++++++++++++++-------------------
fs/isofs/compress.c | 13 +++++-----
include/linux/bootmem_info.h | 25 +++++++++++++------
include/linux/ksm.h | 7 +++---
include/linux/mm_types.h | 6 ++---
include/linux/pagemap.h | 58 ++++++-------------------------------------
include/linux/rmap.h | 12 ++++-----
kernel/events/core.c | 2 --
kernel/watch_queue.c | 4 +--
mm/bootmem_info.c | 11 ++++----
mm/huge_memory.c | 18 +++++++-------
mm/internal.h | 13 +++++++---
mm/ksm.c | 5 ++--
mm/memory-failure.c | 28 +++++++++++----------
mm/page_vma_mapped.c | 5 ++--
mm/percpu.c | 4 +--
mm/rmap.c | 18 ++++++++------
mm/sparse.c | 8 +++---
mm/util.c | 2 +-
23 files changed, 153 insertions(+), 176 deletions(-)
... mostly it's a 1:1 replacement of page with folio, or ->index with
->private, but we get to delete some stuff along the way.
[1] https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
Yes, page->mapping is next on the list in case you're touching
a page->index and notice a page->mapping next door to it.
reply other threads:[~2024-07-23 3:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=Zp8fgUSIBGQ1TN0D@casper.infradead.org \
--to=willy@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).