[f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[Li Zetao via Linux-f2fs-devel]

Hi all,

In btrfs, because there are some interfaces that do not use folio,
there is page-folio-page mutual conversion. This patch set should
clean up folio-page conversion as much as possible and use folio
directly to reduce invalid conversions.

This patch set starts with the rectification of function parameters,
using folio as parameters directly. And some of those functions have
already been converted to folio internally, so this part has little
impact. 

I have tested with fsstress more than 10 hours, and no problems were
found. For the convenience of reviewing, I try my best to only modify
a single interface in each patch.

Josef also worked on converting pages to folios, and this patch set was
inspired by him:
https://lore.kernel.org/all/cover.1722022376.git.josef@toxicpanda.com/

Thanks,
Li Zetao

Li Zetao (14):
  btrfs: convert clear_page_extent_mapped() to take a folio
  btrfs: convert get_next_extent_buffer() to take a folio
  btrfs: convert try_release_subpage_extent_buffer() to take a folio
  btrfs: convert try_release_extent_buffer() to take a folio
  btrfs: convert read_key_bytes() to take a folio
  btrfs: convert submit_eb_subpage() to take a folio
  btrfs: convert submit_eb_page() to take a folio
  btrfs: convert try_release_extent_state() to take a folio
  btrfs: convert try_release_extent_mapping() to take a folio
  btrfs: convert zlib_decompress() to take a folio
  btrfs: convert lzo_decompress() to take a folio
  btrfs: convert zstd_decompress() to take a folio
  btrfs: convert btrfs_decompress() to take a folio
  btrfs: convert copy_inline_to_page() to use folio

 fs/btrfs/compression.c | 14 +++----
 fs/btrfs/compression.h |  8 ++--
 fs/btrfs/disk-io.c     |  2 +-
 fs/btrfs/extent_io.c   | 92 ++++++++++++++++++++----------------------
 fs/btrfs/extent_io.h   |  6 +--
 fs/btrfs/inode.c       |  8 ++--
 fs/btrfs/lzo.c         | 12 +++---
 fs/btrfs/reflink.c     | 35 ++++++++--------
 fs/btrfs/verity.c      | 14 +++----
 fs/btrfs/zlib.c        | 14 +++----
 fs/btrfs/zstd.c        | 16 ++++----
 11 files changed, 109 insertions(+), 112 deletions(-)

-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 01/14] btrfs: convert clear_page_extent_mapped() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 9 ++++-----
 fs/btrfs/extent_io.h | 2 +-
 fs/btrfs/inode.c     | 4 ++--
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 822e2bf8bc99..3c2ad5c9990d 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -951,18 +951,17 @@ int set_folio_extent_mapped(struct folio *folio)
 	return 0;
 }
 
-void clear_page_extent_mapped(struct page *page)
+void clear_page_extent_mapped(struct folio *folio)
 {
-	struct folio *folio = page_folio(page);
 	struct btrfs_fs_info *fs_info;
 
-	ASSERT(page->mapping);
+	ASSERT(folio->mapping);
 
 	if (!folio_test_private(folio))
 		return;
 
-	fs_info = page_to_fs_info(page);
-	if (btrfs_is_subpage(fs_info, page->mapping))
+	fs_info = folio_to_fs_info(folio);
+	if (btrfs_is_subpage(fs_info, folio->mapping))
 		return btrfs_detach_subpage(fs_info, folio);
 
 	folio_detach_private(folio);
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index b38460279b99..236da2231a0e 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -249,7 +249,7 @@ int btree_write_cache_pages(struct address_space *mapping,
 void btrfs_readahead(struct readahead_control *rac);
 int set_folio_extent_mapped(struct folio *folio);
 int set_page_extent_mapped(struct page *page);
-void clear_page_extent_mapped(struct page *page);
+void clear_page_extent_mapped(struct folio *folio);
 
 struct extent_buffer *alloc_extent_buffer(struct btrfs_fs_info *fs_info,
 					  u64 start, u64 owner_root, int level);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a8ad540d6de2..5e3b834cc72b 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7240,7 +7240,7 @@ static bool __btrfs_release_folio(struct folio *folio, gfp_t gfp_flags)
 {
 	if (try_release_extent_mapping(&folio->page, gfp_flags)) {
 		wait_subpage_spinlock(folio);
-		clear_page_extent_mapped(&folio->page);
+		clear_page_extent_mapped(folio);
 		return true;
 	}
 	return false;
@@ -7438,7 +7438,7 @@ static void btrfs_invalidate_folio(struct folio *folio, size_t offset,
 	btrfs_folio_clear_checked(fs_info, folio, folio_pos(folio), folio_size(folio));
 	if (!inode_evicting)
 		__btrfs_release_folio(folio, GFP_NOFS);
-	clear_page_extent_mapped(&folio->page);
+	clear_page_extent_mapped(folio);
 }
 
 static int btrfs_truncate(struct btrfs_inode *inode, bool skip_writeback)
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. And use folio_pos instend of page_offset, which is more
consistent with folio usage.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 3c2ad5c9990d..b9d159fcbbc5 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4135,17 +4135,17 @@ void memmove_extent_buffer(const struct extent_buffer *dst,
 
 #define GANG_LOOKUP_SIZE	16
 static struct extent_buffer *get_next_extent_buffer(
-		const struct btrfs_fs_info *fs_info, struct page *page, u64 bytenr)
+		const struct btrfs_fs_info *fs_info, struct folio *folio, u64 bytenr)
 {
 	struct extent_buffer *gang[GANG_LOOKUP_SIZE];
 	struct extent_buffer *found = NULL;
-	u64 page_start = page_offset(page);
-	u64 cur = page_start;
+	u64 folio_start = folio_pos(folio);
+	u64 cur = folio_start;
 
-	ASSERT(in_range(bytenr, page_start, PAGE_SIZE));
+	ASSERT(in_range(bytenr, folio_start, PAGE_SIZE));
 	lockdep_assert_held(&fs_info->buffer_lock);
 
-	while (cur < page_start + PAGE_SIZE) {
+	while (cur < folio_start + PAGE_SIZE) {
 		int ret;
 		int i;
 
@@ -4157,7 +4157,7 @@ static struct extent_buffer *get_next_extent_buffer(
 			goto out;
 		for (i = 0; i < ret; i++) {
 			/* Already beyond page end */
-			if (gang[i]->start >= page_start + PAGE_SIZE)
+			if (gang[i]->start >= folio_start + PAGE_SIZE)
 				goto out;
 			/* Found one */
 			if (gang[i]->start >= bytenr) {
@@ -4190,7 +4190,7 @@ static int try_release_subpage_extent_buffer(struct page *page)
 		 * with spinlock rather than RCU.
 		 */
 		spin_lock(&fs_info->buffer_lock);
-		eb = get_next_extent_buffer(fs_info, page, cur);
+		eb = get_next_extent_buffer(fs_info, page_folio(page), cur);
 		if (!eb) {
 			/* No more eb in the page range after or at cur */
 			spin_unlock(&fs_info->buffer_lock);
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 03/14] btrfs: convert try_release_subpage_extent_buffer() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. And use folio_pos instend of page_offset, which is more
consistent with folio usage. At the same time, folio_test_private can
handle folio directly without converting from page to folio first.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index b9d159fcbbc5..77c1f69f4229 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4171,11 +4171,11 @@ static struct extent_buffer *get_next_extent_buffer(
 	return found;
 }
 
-static int try_release_subpage_extent_buffer(struct page *page)
+static int try_release_subpage_extent_buffer(struct folio *folio)
 {
-	struct btrfs_fs_info *fs_info = page_to_fs_info(page);
-	u64 cur = page_offset(page);
-	const u64 end = page_offset(page) + PAGE_SIZE;
+	struct btrfs_fs_info *fs_info = folio_to_fs_info(folio);
+	u64 cur = folio_pos(folio);
+	const u64 end = cur + PAGE_SIZE;
 	int ret;
 
 	while (cur < end) {
@@ -4190,7 +4190,7 @@ static int try_release_subpage_extent_buffer(struct page *page)
 		 * with spinlock rather than RCU.
 		 */
 		spin_lock(&fs_info->buffer_lock);
-		eb = get_next_extent_buffer(fs_info, page_folio(page), cur);
+		eb = get_next_extent_buffer(fs_info, folio, cur);
 		if (!eb) {
 			/* No more eb in the page range after or at cur */
 			spin_unlock(&fs_info->buffer_lock);
@@ -4231,12 +4231,12 @@ static int try_release_subpage_extent_buffer(struct page *page)
 	 * Finally to check if we have cleared folio private, as if we have
 	 * released all ebs in the page, the folio private should be cleared now.
 	 */
-	spin_lock(&page->mapping->i_private_lock);
-	if (!folio_test_private(page_folio(page)))
+	spin_lock(&folio->mapping->i_private_lock);
+	if (!folio_test_private(folio))
 		ret = 1;
 	else
 		ret = 0;
-	spin_unlock(&page->mapping->i_private_lock);
+	spin_unlock(&folio->mapping->i_private_lock);
 	return ret;
 
 }
@@ -4247,7 +4247,7 @@ int try_release_extent_buffer(struct page *page)
 	struct extent_buffer *eb;
 
 	if (page_to_fs_info(page)->nodesize < PAGE_SIZE)
-		return try_release_subpage_extent_buffer(page);
+		return try_release_subpage_extent_buffer(page_folio(page));
 
 	/*
 	 * We need to make sure nobody is changing folio private, as we rely on
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 04/14] btrfs: convert try_release_extent_buffer() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/disk-io.c   |  2 +-
 fs/btrfs/extent_io.c | 15 +++++++--------
 fs/btrfs/extent_io.h |  2 +-
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index a6f5441e62d1..ca2f52a28fb0 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -525,7 +525,7 @@ static bool btree_release_folio(struct folio *folio, gfp_t gfp_flags)
 	if (folio_test_writeback(folio) || folio_test_dirty(folio))
 		return false;
 
-	return try_release_extent_buffer(&folio->page);
+	return try_release_extent_buffer(folio);
 }
 
 static void btree_invalidate_folio(struct folio *folio, size_t offset,
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 77c1f69f4229..a0102b9b67ff 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4241,21 +4241,20 @@ static int try_release_subpage_extent_buffer(struct folio *folio)
 
 }
 
-int try_release_extent_buffer(struct page *page)
+int try_release_extent_buffer(struct folio *folio)
 {
-	struct folio *folio = page_folio(page);
 	struct extent_buffer *eb;
 
-	if (page_to_fs_info(page)->nodesize < PAGE_SIZE)
-		return try_release_subpage_extent_buffer(page_folio(page));
+	if (folio_to_fs_info(folio)->nodesize < PAGE_SIZE)
+		return try_release_subpage_extent_buffer(folio);
 
 	/*
 	 * We need to make sure nobody is changing folio private, as we rely on
 	 * folio private as the pointer to extent buffer.
 	 */
-	spin_lock(&page->mapping->i_private_lock);
+	spin_lock(&folio->mapping->i_private_lock);
 	if (!folio_test_private(folio)) {
-		spin_unlock(&page->mapping->i_private_lock);
+		spin_unlock(&folio->mapping->i_private_lock);
 		return 1;
 	}
 
@@ -4270,10 +4269,10 @@ int try_release_extent_buffer(struct page *page)
 	spin_lock(&eb->refs_lock);
 	if (atomic_read(&eb->refs) != 1 || extent_buffer_under_io(eb)) {
 		spin_unlock(&eb->refs_lock);
-		spin_unlock(&page->mapping->i_private_lock);
+		spin_unlock(&folio->mapping->i_private_lock);
 		return 0;
 	}
-	spin_unlock(&page->mapping->i_private_lock);
+	spin_unlock(&folio->mapping->i_private_lock);
 
 	/*
 	 * If tree ref isn't set then we know the ref on this eb is a real ref,
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index 236da2231a0e..f4c93ca46bdd 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -237,7 +237,7 @@ static inline void extent_changeset_free(struct extent_changeset *changeset)
 }
 
 bool try_release_extent_mapping(struct page *page, gfp_t mask);
-int try_release_extent_buffer(struct page *page);
+int try_release_extent_buffer(struct folio *folio);
 
 int btrfs_read_folio(struct file *file, struct folio *folio);
 void extent_write_locked_range(struct inode *inode, const struct folio *locked_folio,
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 05/14] btrfs: convert read_key_bytes() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. Moreover, use kmap_local_folio() instend of kmap_local_page(),
which is more consistent with folio usage.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/verity.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/btrfs/verity.c b/fs/btrfs/verity.c
index 4042dd6437ae..e36dc99021a0 100644
--- a/fs/btrfs/verity.c
+++ b/fs/btrfs/verity.c
@@ -284,7 +284,7 @@ static int write_key_bytes(struct btrfs_inode *inode, u8 key_type, u64 offset,
  *              page and ignore dest, but it must still be non-NULL to avoid the
  *              counting-only behavior.
  * @len:        length in bytes to read
- * @dest_page:  copy into this page instead of the dest buffer
+ * @dest_folio: copy into this folio instead of the dest buffer
  *
  * Helper function to read items from the btree.  This returns the number of
  * bytes read or < 0 for errors.  We can return short reads if the items don't
@@ -294,7 +294,7 @@ static int write_key_bytes(struct btrfs_inode *inode, u8 key_type, u64 offset,
  * Returns number of bytes read or a negative error code on failure.
  */
 static int read_key_bytes(struct btrfs_inode *inode, u8 key_type, u64 offset,
-			  char *dest, u64 len, struct page *dest_page)
+			  char *dest, u64 len, struct folio *dest_folio)
 {
 	struct btrfs_path *path;
 	struct btrfs_root *root = inode->root;
@@ -314,7 +314,7 @@ static int read_key_bytes(struct btrfs_inode *inode, u8 key_type, u64 offset,
 	if (!path)
 		return -ENOMEM;
 
-	if (dest_page)
+	if (dest_folio)
 		path->reada = READA_FORWARD;
 
 	key.objectid = btrfs_ino(inode);
@@ -371,15 +371,15 @@ static int read_key_bytes(struct btrfs_inode *inode, u8 key_type, u64 offset,
 		copy_offset = offset - key.offset;
 
 		if (dest) {
-			if (dest_page)
-				kaddr = kmap_local_page(dest_page);
+			if (dest_folio)
+				kaddr = kmap_local_folio(dest_folio, 0);
 
 			data = btrfs_item_ptr(leaf, path->slots[0], void);
 			read_extent_buffer(leaf, kaddr + dest_offset,
 					   (unsigned long)data + copy_offset,
 					   copy_bytes);
 
-			if (dest_page)
+			if (dest_folio)
 				kunmap_local(kaddr);
 		}
 
@@ -762,7 +762,7 @@ static struct page *btrfs_read_merkle_tree_page(struct inode *inode,
 	 * [ inode objectid, BTRFS_MERKLE_ITEM_KEY, offset in bytes ]
 	 */
 	ret = read_key_bytes(BTRFS_I(inode), BTRFS_VERITY_MERKLE_ITEM_KEY, off,
-			     folio_address(folio), PAGE_SIZE, &folio->page);
+			     folio_address(folio), PAGE_SIZE, folio);
 	if (ret < 0) {
 		folio_put(folio);
 		return ERR_PTR(ret);
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 06/14] btrfs: convert submit_eb_subpage() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. Moreover, use folio_pos() instend of page_offset(),
which is more consistent with folio usage.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index a0102b9b67ff..ca458237ac35 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -1818,12 +1818,11 @@ static noinline_for_stack void write_one_eb(struct extent_buffer *eb,
  * Return >=0 for the number of submitted extent buffers.
  * Return <0 for fatal error.
  */
-static int submit_eb_subpage(struct page *page, struct writeback_control *wbc)
+static int submit_eb_subpage(struct folio *folio, struct writeback_control *wbc)
 {
-	struct btrfs_fs_info *fs_info = page_to_fs_info(page);
-	struct folio *folio = page_folio(page);
+	struct btrfs_fs_info *fs_info = folio_to_fs_info(folio);
 	int submitted = 0;
-	u64 page_start = page_offset(page);
+	u64 folio_start = folio_pos(folio);
 	int bit_start = 0;
 	int sectors_per_node = fs_info->nodesize >> fs_info->sectorsize_bits;
 
@@ -1838,21 +1837,21 @@ static int submit_eb_subpage(struct page *page, struct writeback_control *wbc)
 		 * Take private lock to ensure the subpage won't be detached
 		 * in the meantime.
 		 */
-		spin_lock(&page->mapping->i_private_lock);
+		spin_lock(&folio->mapping->i_private_lock);
 		if (!folio_test_private(folio)) {
-			spin_unlock(&page->mapping->i_private_lock);
+			spin_unlock(&folio->mapping->i_private_lock);
 			break;
 		}
 		spin_lock_irqsave(&subpage->lock, flags);
 		if (!test_bit(bit_start + fs_info->subpage_info->dirty_offset,
 			      subpage->bitmaps)) {
 			spin_unlock_irqrestore(&subpage->lock, flags);
-			spin_unlock(&page->mapping->i_private_lock);
+			spin_unlock(&folio->mapping->i_private_lock);
 			bit_start++;
 			continue;
 		}
 
-		start = page_start + bit_start * fs_info->sectorsize;
+		start = folio_start + bit_start * fs_info->sectorsize;
 		bit_start += sectors_per_node;
 
 		/*
@@ -1861,7 +1860,7 @@ static int submit_eb_subpage(struct page *page, struct writeback_control *wbc)
 		 */
 		eb = find_extent_buffer_nolock(fs_info, start);
 		spin_unlock_irqrestore(&subpage->lock, flags);
-		spin_unlock(&page->mapping->i_private_lock);
+		spin_unlock(&folio->mapping->i_private_lock);
 
 		/*
 		 * The eb has already reached 0 refs thus find_extent_buffer()
@@ -1912,7 +1911,7 @@ static int submit_eb_page(struct page *page, struct btrfs_eb_write_context *ctx)
 		return 0;
 
 	if (page_to_fs_info(page)->nodesize < PAGE_SIZE)
-		return submit_eb_subpage(page, wbc);
+		return submit_eb_subpage(folio, wbc);
 
 	spin_lock(&mapping->i_private_lock);
 	if (!folio_test_private(folio)) {
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 07/14] btrfs: convert submit_eb_page() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index ca458237ac35..e16477ef0bfb 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -1899,18 +1899,17 @@ static int submit_eb_subpage(struct folio *folio, struct writeback_control *wbc)
  * previous call.
  * Return <0 for fatal error.
  */
-static int submit_eb_page(struct page *page, struct btrfs_eb_write_context *ctx)
+static int submit_eb_page(struct folio *folio, struct btrfs_eb_write_context *ctx)
 {
 	struct writeback_control *wbc = ctx->wbc;
-	struct address_space *mapping = page->mapping;
-	struct folio *folio = page_folio(page);
+	struct address_space *mapping = folio->mapping;
 	struct extent_buffer *eb;
 	int ret;
 
 	if (!folio_test_private(folio))
 		return 0;
 
-	if (page_to_fs_info(page)->nodesize < PAGE_SIZE)
+	if (folio_to_fs_info(folio)->nodesize < PAGE_SIZE)
 		return submit_eb_subpage(folio, wbc);
 
 	spin_lock(&mapping->i_private_lock);
@@ -2009,7 +2008,7 @@ int btree_write_cache_pages(struct address_space *mapping,
 		for (i = 0; i < nr_folios; i++) {
 			struct folio *folio = fbatch.folios[i];
 
-			ret = submit_eb_page(&folio->page, &ctx);
+			ret = submit_eb_page(folio, &ctx);
 			if (ret == 0)
 				continue;
 			if (ret < 0) {
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 08/14] btrfs: convert try_release_extent_state() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. Moreover, use folio_pos() instend of page_offset(),
which is more consistent with folio usage.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index e16477ef0bfb..27ca7a56d8f5 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2397,9 +2397,9 @@ int extent_invalidate_folio(struct extent_io_tree *tree,
  * to drop the page.
  */
 static bool try_release_extent_state(struct extent_io_tree *tree,
-				    struct page *page, gfp_t mask)
+				    struct folio *folio, gfp_t mask)
 {
-	u64 start = page_offset(page);
+	u64 start = folio_pos(folio);
 	u64 end = start + PAGE_SIZE - 1;
 	bool ret;
 
@@ -2508,7 +2508,7 @@ bool try_release_extent_mapping(struct page *page, gfp_t mask)
 			cond_resched();
 		}
 	}
-	return try_release_extent_state(io_tree, page, mask);
+	return try_release_extent_state(io_tree, folio, mask);
 }
 
 static void __free_extent_buffer(struct extent_buffer *eb)
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 09/14] btrfs: convert try_release_extent_mapping() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. And page_to_inode() can be replaced with folio_to_inode() now.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/extent_io.c | 6 +++---
 fs/btrfs/extent_io.h | 2 +-
 fs/btrfs/inode.c     | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 27ca7a56d8f5..cfd523b523b3 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2435,11 +2435,11 @@ static bool try_release_extent_state(struct extent_io_tree *tree,
  * in the range corresponding to the page, both state records and extent
  * map records are removed
  */
-bool try_release_extent_mapping(struct page *page, gfp_t mask)
+bool try_release_extent_mapping(struct folio *folio, gfp_t mask)
 {
-	u64 start = page_offset(page);
+	u64 start = folio_pos(folio);
 	u64 end = start + PAGE_SIZE - 1;
-	struct btrfs_inode *inode = page_to_inode(page);
+	struct btrfs_inode *inode = folio_to_inode(folio);
 	struct extent_io_tree *io_tree = &inode->io_tree;
 
 	while (start <= end) {
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index f4c93ca46bdd..d1c54788d444 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -236,7 +236,7 @@ static inline void extent_changeset_free(struct extent_changeset *changeset)
 	kfree(changeset);
 }
 
-bool try_release_extent_mapping(struct page *page, gfp_t mask);
+bool try_release_extent_mapping(struct folio *folio, gfp_t mask);
 int try_release_extent_buffer(struct folio *folio);
 
 int btrfs_read_folio(struct file *file, struct folio *folio);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 5e3b834cc72b..e844c409c12a 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7238,7 +7238,7 @@ static int btrfs_launder_folio(struct folio *folio)
 
 static bool __btrfs_release_folio(struct folio *folio, gfp_t gfp_flags)
 {
-	if (try_release_extent_mapping(&folio->page, gfp_flags)) {
+	if (try_release_extent_mapping(folio, gfp_flags)) {
 		wait_subpage_spinlock(folio);
 		clear_page_extent_mapped(folio);
 		return true;
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 10/14] btrfs: convert zlib_decompress() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. And memcpy_to_page() can be replaced with memcpy_to_folio().
But there is no memzero_folio(), but it can be replaced equivalently by
folio_zero_range().

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/compression.c |  2 +-
 fs/btrfs/compression.h |  2 +-
 fs/btrfs/zlib.c        | 14 +++++++-------
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 832ab8984c41..19d18f875563 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -142,7 +142,7 @@ static int compression_decompress(int type, struct list_head *ws,
 		unsigned long dest_pgoff, size_t srclen, size_t destlen)
 {
 	switch (type) {
-	case BTRFS_COMPRESS_ZLIB: return zlib_decompress(ws, data_in, dest_page,
+	case BTRFS_COMPRESS_ZLIB: return zlib_decompress(ws, data_in, page_folio(dest_page),
 						dest_pgoff, srclen, destlen);
 	case BTRFS_COMPRESS_LZO:  return lzo_decompress(ws, data_in, dest_page,
 						dest_pgoff, srclen, destlen);
diff --git a/fs/btrfs/compression.h b/fs/btrfs/compression.h
index 5d01f092ae13..f4f7a981cb90 100644
--- a/fs/btrfs/compression.h
+++ b/fs/btrfs/compression.h
@@ -162,7 +162,7 @@ int zlib_compress_folios(struct list_head *ws, struct address_space *mapping,
 		unsigned long *total_in, unsigned long *total_out);
 int zlib_decompress_bio(struct list_head *ws, struct compressed_bio *cb);
 int zlib_decompress(struct list_head *ws, const u8 *data_in,
-		struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
+		struct folio *dest_folio, unsigned long dest_pgoff, size_t srclen,
 		size_t destlen);
 struct list_head *zlib_alloc_workspace(unsigned int level);
 void zlib_free_workspace(struct list_head *ws);
diff --git a/fs/btrfs/zlib.c b/fs/btrfs/zlib.c
index 8aa82ee1991e..4ca7ff38234c 100644
--- a/fs/btrfs/zlib.c
+++ b/fs/btrfs/zlib.c
@@ -393,7 +393,7 @@ int zlib_decompress_bio(struct list_head *ws, struct compressed_bio *cb)
 }
 
 int zlib_decompress(struct list_head *ws, const u8 *data_in,
-		struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
+		struct folio *dest_folio, unsigned long dest_pgoff, size_t srclen,
 		size_t destlen)
 {
 	struct workspace *workspace = list_entry(ws, struct workspace, list);
@@ -421,12 +421,12 @@ int zlib_decompress(struct list_head *ws, const u8 *data_in,
 
 	ret = zlib_inflateInit2(&workspace->strm, wbits);
 	if (unlikely(ret != Z_OK)) {
-		struct btrfs_inode *inode = BTRFS_I(dest_page->mapping->host);
+		struct btrfs_inode *inode = folio_to_inode(dest_folio);
 
 		btrfs_err(inode->root->fs_info,
 		"zlib decompression init failed, error %d root %llu inode %llu offset %llu",
 			  ret, btrfs_root_id(inode->root), btrfs_ino(inode),
-			  page_offset(dest_page));
+			  folio_pos(dest_folio));
 		return -EIO;
 	}
 
@@ -439,16 +439,16 @@ int zlib_decompress(struct list_head *ws, const u8 *data_in,
 	if (ret != Z_STREAM_END)
 		goto out;
 
-	memcpy_to_page(dest_page, dest_pgoff, workspace->buf, to_copy);
+	memcpy_to_folio(dest_folio, dest_pgoff, workspace->buf, to_copy);
 
 out:
 	if (unlikely(to_copy != destlen)) {
-		struct btrfs_inode *inode = BTRFS_I(dest_page->mapping->host);
+		struct btrfs_inode *inode = folio_to_inode(dest_folio);
 
 		btrfs_err(inode->root->fs_info,
 "zlib decompression failed, error %d root %llu inode %llu offset %llu decompressed %lu expected %zu",
 			  ret, btrfs_root_id(inode->root), btrfs_ino(inode),
-			  page_offset(dest_page), to_copy, destlen);
+			  folio_pos(dest_folio), to_copy, destlen);
 		ret = -EIO;
 	} else {
 		ret = 0;
@@ -457,7 +457,7 @@ int zlib_decompress(struct list_head *ws, const u8 *data_in,
 	zlib_inflateEnd(&workspace->strm);
 
 	if (unlikely(to_copy < destlen))
-		memzero_page(dest_page, dest_pgoff + to_copy, destlen - to_copy);
+		folio_zero_range(dest_folio, dest_pgoff + to_copy, destlen - to_copy);
 	return ret;
 }
 
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 11/14] btrfs: convert lzo_decompress() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. And memcpy_to_page() can be replaced with memcpy_to_folio().
But there is no memzero_folio(), but it can be replaced equivalently by
folio_zero_range().

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/compression.c |  2 +-
 fs/btrfs/compression.h |  2 +-
 fs/btrfs/lzo.c         | 12 ++++++------
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 19d18f875563..8e67203ab97d 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -144,7 +144,7 @@ static int compression_decompress(int type, struct list_head *ws,
 	switch (type) {
 	case BTRFS_COMPRESS_ZLIB: return zlib_decompress(ws, data_in, page_folio(dest_page),
 						dest_pgoff, srclen, destlen);
-	case BTRFS_COMPRESS_LZO:  return lzo_decompress(ws, data_in, dest_page,
+	case BTRFS_COMPRESS_LZO:  return lzo_decompress(ws, data_in, page_folio(dest_page),
 						dest_pgoff, srclen, destlen);
 	case BTRFS_COMPRESS_ZSTD: return zstd_decompress(ws, data_in, dest_page,
 						dest_pgoff, srclen, destlen);
diff --git a/fs/btrfs/compression.h b/fs/btrfs/compression.h
index f4f7a981cb90..4b5a7ba54815 100644
--- a/fs/btrfs/compression.h
+++ b/fs/btrfs/compression.h
@@ -173,7 +173,7 @@ int lzo_compress_folios(struct list_head *ws, struct address_space *mapping,
 		unsigned long *total_in, unsigned long *total_out);
 int lzo_decompress_bio(struct list_head *ws, struct compressed_bio *cb);
 int lzo_decompress(struct list_head *ws, const u8 *data_in,
-		struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
+		struct folio *dest_folio, unsigned long dest_pgoff, size_t srclen,
 		size_t destlen);
 struct list_head *lzo_alloc_workspace(unsigned int level);
 void lzo_free_workspace(struct list_head *ws);
diff --git a/fs/btrfs/lzo.c b/fs/btrfs/lzo.c
index 1e2a68b8f62d..72856f6775f7 100644
--- a/fs/btrfs/lzo.c
+++ b/fs/btrfs/lzo.c
@@ -438,11 +438,11 @@ int lzo_decompress_bio(struct list_head *ws, struct compressed_bio *cb)
 }
 
 int lzo_decompress(struct list_head *ws, const u8 *data_in,
-		struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
+		struct folio *dest_folio, unsigned long dest_pgoff, size_t srclen,
 		size_t destlen)
 {
 	struct workspace *workspace = list_entry(ws, struct workspace, list);
-	struct btrfs_fs_info *fs_info = page_to_fs_info(dest_page);
+	struct btrfs_fs_info *fs_info = folio_to_fs_info(dest_folio);
 	const u32 sectorsize = fs_info->sectorsize;
 	size_t in_len;
 	size_t out_len;
@@ -467,22 +467,22 @@ int lzo_decompress(struct list_head *ws, const u8 *data_in,
 	out_len = sectorsize;
 	ret = lzo1x_decompress_safe(data_in, in_len, workspace->buf, &out_len);
 	if (unlikely(ret != LZO_E_OK)) {
-		struct btrfs_inode *inode = BTRFS_I(dest_page->mapping->host);
+		struct btrfs_inode *inode = folio_to_inode(dest_folio);
 
 		btrfs_err(fs_info,
 		"lzo decompression failed, error %d root %llu inode %llu offset %llu",
 			  ret, btrfs_root_id(inode->root), btrfs_ino(inode),
-			  page_offset(dest_page));
+			  folio_pos(dest_folio));
 		ret = -EIO;
 		goto out;
 	}
 
 	ASSERT(out_len <= sectorsize);
-	memcpy_to_page(dest_page, dest_pgoff, workspace->buf, out_len);
+	memcpy_to_folio(dest_folio, dest_pgoff, workspace->buf, out_len);
 	/* Early end, considered as an error. */
 	if (unlikely(out_len < destlen)) {
 		ret = -EIO;
-		memzero_page(dest_page, dest_pgoff + out_len, destlen - out_len);
+		folio_zero_range(dest_folio, dest_pgoff + out_len, destlen - out_len);
 	}
 out:
 	return ret;
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 12/14] btrfs: convert zstd_decompress() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. And memcpy_to_page() can be replaced with memcpy_to_folio().
But there is no memzero_folio(), but it can be replaced equivalently by
folio_zero_range().

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/compression.c |  2 +-
 fs/btrfs/compression.h |  2 +-
 fs/btrfs/zstd.c        | 16 ++++++++--------
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 8e67203ab97d..eab79edeb64c 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -146,7 +146,7 @@ static int compression_decompress(int type, struct list_head *ws,
 						dest_pgoff, srclen, destlen);
 	case BTRFS_COMPRESS_LZO:  return lzo_decompress(ws, data_in, page_folio(dest_page),
 						dest_pgoff, srclen, destlen);
-	case BTRFS_COMPRESS_ZSTD: return zstd_decompress(ws, data_in, dest_page,
+	case BTRFS_COMPRESS_ZSTD: return zstd_decompress(ws, data_in, page_folio(dest_page),
 						dest_pgoff, srclen, destlen);
 	case BTRFS_COMPRESS_NONE:
 	default:
diff --git a/fs/btrfs/compression.h b/fs/btrfs/compression.h
index 4b5a7ba54815..d2453cf28eef 100644
--- a/fs/btrfs/compression.h
+++ b/fs/btrfs/compression.h
@@ -183,7 +183,7 @@ int zstd_compress_folios(struct list_head *ws, struct address_space *mapping,
 		unsigned long *total_in, unsigned long *total_out);
 int zstd_decompress_bio(struct list_head *ws, struct compressed_bio *cb);
 int zstd_decompress(struct list_head *ws, const u8 *data_in,
-		struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
+		struct folio *dest_folio, unsigned long dest_pgoff, size_t srclen,
 		size_t destlen);
 void zstd_init_workspace_manager(void);
 void zstd_cleanup_workspace_manager(void);
diff --git a/fs/btrfs/zstd.c b/fs/btrfs/zstd.c
index 05cf7cebc17c..866607fd3e58 100644
--- a/fs/btrfs/zstd.c
+++ b/fs/btrfs/zstd.c
@@ -656,11 +656,11 @@ int zstd_decompress_bio(struct list_head *ws, struct compressed_bio *cb)
 }
 
 int zstd_decompress(struct list_head *ws, const u8 *data_in,
-		struct page *dest_page, unsigned long dest_pgoff, size_t srclen,
+		struct folio *dest_folio, unsigned long dest_pgoff, size_t srclen,
 		size_t destlen)
 {
 	struct workspace *workspace = list_entry(ws, struct workspace, list);
-	struct btrfs_fs_info *fs_info = btrfs_sb(dest_page->mapping->host->i_sb);
+	struct btrfs_fs_info *fs_info = btrfs_sb(folio_inode(dest_folio)->i_sb);
 	const u32 sectorsize = fs_info->sectorsize;
 	zstd_dstream *stream;
 	int ret = 0;
@@ -669,12 +669,12 @@ int zstd_decompress(struct list_head *ws, const u8 *data_in,
 	stream = zstd_init_dstream(
 			ZSTD_BTRFS_MAX_INPUT, workspace->mem, workspace->size);
 	if (unlikely(!stream)) {
-		struct btrfs_inode *inode = BTRFS_I(dest_page->mapping->host);
+		struct btrfs_inode *inode = folio_to_inode(dest_folio);
 
 		btrfs_err(inode->root->fs_info,
 		"zstd decompression init failed, root %llu inode %llu offset %llu",
 			  btrfs_root_id(inode->root), btrfs_ino(inode),
-			  page_offset(dest_page));
+			  folio_pos(dest_folio));
 		ret = -EIO;
 		goto finish;
 	}
@@ -693,21 +693,21 @@ int zstd_decompress(struct list_head *ws, const u8 *data_in,
 	 */
 	ret = zstd_decompress_stream(stream, &workspace->out_buf, &workspace->in_buf);
 	if (unlikely(zstd_is_error(ret))) {
-		struct btrfs_inode *inode = BTRFS_I(dest_page->mapping->host);
+		struct btrfs_inode *inode = folio_to_inode(dest_folio);
 
 		btrfs_err(inode->root->fs_info,
 		"zstd decompression failed, error %d root %llu inode %llu offset %llu",
 			  zstd_get_error_code(ret), btrfs_root_id(inode->root),
-			  btrfs_ino(inode), page_offset(dest_page));
+			  btrfs_ino(inode), folio_pos(dest_folio));
 		goto finish;
 	}
 	to_copy = workspace->out_buf.pos;
-	memcpy_to_page(dest_page, dest_pgoff, workspace->out_buf.dst, to_copy);
+	memcpy_to_folio(dest_folio, dest_pgoff, workspace->out_buf.dst, to_copy);
 finish:
 	/* Error or early end. */
 	if (unlikely(to_copy < destlen)) {
 		ret = -EIO;
-		memzero_page(dest_page, dest_pgoff + to_copy, destlen - to_copy);
+		folio_zero_range(dest_folio, dest_pgoff + to_copy, destlen - to_copy);
 	}
 	return ret;
 }
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 13/14] btrfs: convert btrfs_decompress() to take a folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. Based on the previous patch, the compression path can be
directly used in folio without converting to page.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/compression.c | 14 +++++++-------
 fs/btrfs/compression.h |  2 +-
 fs/btrfs/inode.c       |  2 +-
 fs/btrfs/reflink.c     |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index eab79edeb64c..9869944a5acc 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -138,15 +138,15 @@ static int compression_decompress_bio(struct list_head *ws,
 }
 
 static int compression_decompress(int type, struct list_head *ws,
-		const u8 *data_in, struct page *dest_page,
+		const u8 *data_in, struct folio *dest_folio,
 		unsigned long dest_pgoff, size_t srclen, size_t destlen)
 {
 	switch (type) {
-	case BTRFS_COMPRESS_ZLIB: return zlib_decompress(ws, data_in, page_folio(dest_page),
+	case BTRFS_COMPRESS_ZLIB: return zlib_decompress(ws, data_in, dest_folio,
 						dest_pgoff, srclen, destlen);
-	case BTRFS_COMPRESS_LZO:  return lzo_decompress(ws, data_in, page_folio(dest_page),
+	case BTRFS_COMPRESS_LZO:  return lzo_decompress(ws, data_in, dest_folio,
 						dest_pgoff, srclen, destlen);
-	case BTRFS_COMPRESS_ZSTD: return zstd_decompress(ws, data_in, page_folio(dest_page),
+	case BTRFS_COMPRESS_ZSTD: return zstd_decompress(ws, data_in, dest_folio,
 						dest_pgoff, srclen, destlen);
 	case BTRFS_COMPRESS_NONE:
 	default:
@@ -1061,10 +1061,10 @@ static int btrfs_decompress_bio(struct compressed_bio *cb)
  * single page, and we want to read a single page out of it.
  * start_byte tells us the offset into the compressed data we're interested in
  */
-int btrfs_decompress(int type, const u8 *data_in, struct page *dest_page,
+int btrfs_decompress(int type, const u8 *data_in, struct folio *dest_folio,
 		     unsigned long dest_pgoff, size_t srclen, size_t destlen)
 {
-	struct btrfs_fs_info *fs_info = page_to_fs_info(dest_page);
+	struct btrfs_fs_info *fs_info = folio_to_fs_info(dest_folio);
 	struct list_head *workspace;
 	const u32 sectorsize = fs_info->sectorsize;
 	int ret;
@@ -1077,7 +1077,7 @@ int btrfs_decompress(int type, const u8 *data_in, struct page *dest_page,
 	ASSERT(dest_pgoff + destlen <= PAGE_SIZE && destlen <= sectorsize);
 
 	workspace = get_workspace(type, 0);
-	ret = compression_decompress(type, workspace, data_in, dest_page,
+	ret = compression_decompress(type, workspace, data_in, dest_folio,
 				     dest_pgoff, srclen, destlen);
 	put_workspace(type, workspace);
 
diff --git a/fs/btrfs/compression.h b/fs/btrfs/compression.h
index d2453cf28eef..b6563b6a333e 100644
--- a/fs/btrfs/compression.h
+++ b/fs/btrfs/compression.h
@@ -96,7 +96,7 @@ void __cold btrfs_exit_compress(void);
 int btrfs_compress_folios(unsigned int type_level, struct address_space *mapping,
 			  u64 start, struct folio **folios, unsigned long *out_folios,
 			 unsigned long *total_in, unsigned long *total_out);
-int btrfs_decompress(int type, const u8 *data_in, struct page *dest_page,
+int btrfs_decompress(int type, const u8 *data_in, struct folio *dest_folio,
 		     unsigned long start_byte, size_t srclen, size_t destlen);
 int btrfs_decompress_buf2page(const char *buf, u32 buf_len,
 			      struct compressed_bio *cb, u32 decompressed);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index e844c409c12a..f9ade617700f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -6746,7 +6746,7 @@ static noinline int uncompress_inline(struct btrfs_path *path,
 	read_extent_buffer(leaf, tmp, ptr, inline_size);
 
 	max_size = min_t(unsigned long, PAGE_SIZE, max_size);
-	ret = btrfs_decompress(compress_type, tmp, &folio->page, 0, inline_size,
+	ret = btrfs_decompress(compress_type, tmp, folio, 0, inline_size,
 			       max_size);
 
 	/*
diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
index df6b93b927cd..b768e590a44c 100644
--- a/fs/btrfs/reflink.c
+++ b/fs/btrfs/reflink.c
@@ -118,7 +118,7 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
 		memcpy_to_page(page, offset_in_page(file_offset), data_start,
 			       datal);
 	} else {
-		ret = btrfs_decompress(comp_type, data_start, page,
+		ret = btrfs_decompress(comp_type, data_start, page_folio(page),
 				       offset_in_page(file_offset),
 				       inline_size, datal);
 		if (ret)
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 14/14] btrfs: convert copy_inline_to_page() to use folio

[Li Zetao via Linux-f2fs-devel]

The old page API is being gradually replaced and converted to use folio
to improve code readability and avoid repeated conversion between page
and folio. Moreover find_or_create_page() is compatible API, and it can
replaced with __filemap_get_folio(). Some interfaces have been converted
to use folio before, so the conversion operation from page can be
eliminated here.

Signed-off-by: Li Zetao <lizetao1@huawei.com>
---
 fs/btrfs/reflink.c | 35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
index b768e590a44c..1681d63f03dd 100644
--- a/fs/btrfs/reflink.c
+++ b/fs/btrfs/reflink.c
@@ -66,7 +66,7 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
 	const size_t inline_size = size - btrfs_file_extent_calc_inline_size(0);
 	char *data_start = inline_data + btrfs_file_extent_calc_inline_size(0);
 	struct extent_changeset *data_reserved = NULL;
-	struct page *page = NULL;
+	struct folio *folio = NULL;
 	struct address_space *mapping = inode->vfs_inode.i_mapping;
 	int ret;
 
@@ -83,14 +83,15 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
 	if (ret)
 		goto out;
 
-	page = find_or_create_page(mapping, file_offset >> PAGE_SHIFT,
-				   btrfs_alloc_write_mask(mapping));
-	if (!page) {
+	folio = __filemap_get_folio(mapping, file_offset >> PAGE_SHIFT,
+					FGP_LOCK | FGP_ACCESSED | FGP_CREAT,
+					btrfs_alloc_write_mask(mapping));
+	if (IS_ERR(folio)) {
 		ret = -ENOMEM;
 		goto out_unlock;
 	}
 
-	ret = set_page_extent_mapped(page);
+	ret = set_folio_extent_mapped(folio);
 	if (ret < 0)
 		goto out_unlock;
 
@@ -115,15 +116,15 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
 	set_bit(BTRFS_INODE_NO_DELALLOC_FLUSH, &inode->runtime_flags);
 
 	if (comp_type == BTRFS_COMPRESS_NONE) {
-		memcpy_to_page(page, offset_in_page(file_offset), data_start,
-			       datal);
+		memcpy_to_folio(folio, offset_in_folio(folio, file_offset), data_start,
+					datal);
 	} else {
-		ret = btrfs_decompress(comp_type, data_start, page_folio(page),
-				       offset_in_page(file_offset),
+		ret = btrfs_decompress(comp_type, data_start, folio,
+				       offset_in_folio(folio, file_offset),
 				       inline_size, datal);
 		if (ret)
 			goto out_unlock;
-		flush_dcache_page(page);
+		flush_dcache_folio(folio);
 	}
 
 	/*
@@ -139,15 +140,15 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
 	 * So what's in the range [500, 4095] corresponds to zeroes.
 	 */
 	if (datal < block_size)
-		memzero_page(page, datal, block_size - datal);
+		folio_zero_range(folio, datal, block_size - datal);
 
-	btrfs_folio_set_uptodate(fs_info, page_folio(page), file_offset, block_size);
-	btrfs_folio_clear_checked(fs_info, page_folio(page), file_offset, block_size);
-	btrfs_folio_set_dirty(fs_info, page_folio(page), file_offset, block_size);
+	btrfs_folio_set_uptodate(fs_info, folio, file_offset, block_size);
+	btrfs_folio_clear_checked(fs_info, folio, file_offset, block_size);
+	btrfs_folio_set_dirty(fs_info, folio, file_offset, block_size);
 out_unlock:
-	if (page) {
-		unlock_page(page);
-		put_page(page);
+	if (IS_ERR(folio)) {
+		folio_unlock(folio);
+		folio_put(folio);
 	}
 	if (ret)
 		btrfs_delalloc_release_space(inode, data_reserved, file_offset,
-- 
2.34.1



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 01/14] btrfs: convert clear_page_extent_mapped() to take a folio

[Matthew Wilcox]

On Thu, Aug 22, 2024 at 09:37:01AM +0800, Li Zetao wrote:
> -void clear_page_extent_mapped(struct page *page)
> +void clear_page_extent_mapped(struct folio *folio)

Rename it to clear_folio_extent_mapped()?



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Matthew Wilcox]

On Thu, Aug 22, 2024 at 09:37:02AM +0800, Li Zetao wrote:
>  static struct extent_buffer *get_next_extent_buffer(
> -		const struct btrfs_fs_info *fs_info, struct page *page, u64 bytenr)
> +		const struct btrfs_fs_info *fs_info, struct folio *folio, u64 bytenr)
>  {
>  	struct extent_buffer *gang[GANG_LOOKUP_SIZE];
>  	struct extent_buffer *found = NULL;
> -	u64 page_start = page_offset(page);
> -	u64 cur = page_start;
> +	u64 folio_start = folio_pos(folio);
> +	u64 cur = folio_start;
>  
> -	ASSERT(in_range(bytenr, page_start, PAGE_SIZE));
> +	ASSERT(in_range(bytenr, folio_start, PAGE_SIZE));
>  	lockdep_assert_held(&fs_info->buffer_lock);
>  
> -	while (cur < page_start + PAGE_SIZE) {
> +	while (cur < folio_start + PAGE_SIZE) {

Presumably we want to support large folios in btrfs at some point?
I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
be a bit of a regression for btrfs if it doesn't have large folio
support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 05/14] btrfs: convert read_key_bytes() to take a folio

[Matthew Wilcox]

On Thu, Aug 22, 2024 at 09:37:05AM +0800, Li Zetao wrote:
> @@ -762,7 +762,7 @@ static struct page *btrfs_read_merkle_tree_page(struct inode *inode,
>  	 * [ inode objectid, BTRFS_MERKLE_ITEM_KEY, offset in bytes ]
>  	 */
>  	ret = read_key_bytes(BTRFS_I(inode), BTRFS_VERITY_MERKLE_ITEM_KEY, off,
> -			     folio_address(folio), PAGE_SIZE, &folio->page);
> +			     folio_address(folio), PAGE_SIZE, folio);

So how are we going to read into folios larger than PAGE_SIZE?


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Qu Wenruo via Linux-f2fs-devel]

在 2024/8/22 12:35, Matthew Wilcox 写道:
> On Thu, Aug 22, 2024 at 09:37:02AM +0800, Li Zetao wrote:
>>   static struct extent_buffer *get_next_extent_buffer(
>> -		const struct btrfs_fs_info *fs_info, struct page *page, u64 bytenr)
>> +		const struct btrfs_fs_info *fs_info, struct folio *folio, u64 bytenr)
>>   {
>>   	struct extent_buffer *gang[GANG_LOOKUP_SIZE];
>>   	struct extent_buffer *found = NULL;
>> -	u64 page_start = page_offset(page);
>> -	u64 cur = page_start;
>> +	u64 folio_start = folio_pos(folio);
>> +	u64 cur = folio_start;
>>
>> -	ASSERT(in_range(bytenr, page_start, PAGE_SIZE));
>> +	ASSERT(in_range(bytenr, folio_start, PAGE_SIZE));
>>   	lockdep_assert_held(&fs_info->buffer_lock);
>>
>> -	while (cur < page_start + PAGE_SIZE) {
>> +	while (cur < folio_start + PAGE_SIZE) {
>
> Presumably we want to support large folios in btrfs at some point?

Yes, and we're already working towards that direction.

> I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
> be a bit of a regression for btrfs if it doesn't have large folio
> support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?

AFAIK we're only going to support larger folios to support larger than
PAGE_SIZE sector size so far.
So every folio is still in a fixed size (sector size, >= PAGE_SIZE).

Not familiar with transparent huge page, I thought transparent huge page
is transparent to fs.

Or do we need some special handling?
My uneducated guess is, we will get a larger folio passed to readpage
call back directly?
It's straightforward enough to read all contents for a larger folio,
it's no different to subpage handling.

But what will happen if some writes happened to that larger folio?
Do MM layer detects that and split the folios? Or the fs has to go the
subpage routine (with an extra structure recording all the subpage flags
bitmap)?

Thanks,
Qu


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Qu Wenruo via Linux-f2fs-devel]

在 2024/8/22 12:35, Matthew Wilcox 写道:
> On Thu, Aug 22, 2024 at 09:37:02AM +0800, Li Zetao wrote:
>>   static struct extent_buffer *get_next_extent_buffer(
>> -		const struct btrfs_fs_info *fs_info, struct page *page, u64 bytenr)
>> +		const struct btrfs_fs_info *fs_info, struct folio *folio, u64 bytenr)
>>   {
>>   	struct extent_buffer *gang[GANG_LOOKUP_SIZE];
>>   	struct extent_buffer *found = NULL;
>> -	u64 page_start = page_offset(page);
>> -	u64 cur = page_start;
>> +	u64 folio_start = folio_pos(folio);
>> +	u64 cur = folio_start;
>>
>> -	ASSERT(in_range(bytenr, page_start, PAGE_SIZE));
>> +	ASSERT(in_range(bytenr, folio_start, PAGE_SIZE));
>>   	lockdep_assert_held(&fs_info->buffer_lock);
>>
>> -	while (cur < page_start + PAGE_SIZE) {
>> +	while (cur < folio_start + PAGE_SIZE) {
>
> Presumably we want to support large folios in btrfs at some point?
> I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
> be a bit of a regression for btrfs if it doesn't have large folio
> support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?

Forgot to mention that, this function is only called inside subpage
routine (sectorsize < PAGE_SIZE and nodesize, aka metadata size < PAGE_SIZE)

So PAGE_SIZE is correct. Going folio_size() is only wasting CPU time,
but if you do not feel safe, we can add extra ASSERT() to make sure it's
only called for subpage routine.

Thanks,
Qu


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Matthew Wilcox]

On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> 在 2024/8/22 12:35, Matthew Wilcox 写道:
> > > -	while (cur < page_start + PAGE_SIZE) {
> > > +	while (cur < folio_start + PAGE_SIZE) {
> > 
> > Presumably we want to support large folios in btrfs at some point?
> 
> Yes, and we're already working towards that direction.
> 
> > I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
> > be a bit of a regression for btrfs if it doesn't have large folio
> > support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?
> 
> AFAIK we're only going to support larger folios to support larger than
> PAGE_SIZE sector size so far.

Why do you not want the performance gains from using larger folios?

> So every folio is still in a fixed size (sector size, >= PAGE_SIZE).
> 
> Not familiar with transparent huge page, I thought transparent huge page
> is transparent to fs.
> 
> Or do we need some special handling?
> My uneducated guess is, we will get a larger folio passed to readpage
> call back directly?

Why do you choose to remain uneducated?  It's not like I've been keeping
all of this to myself for the past five years.  I've given dozens of
presentations on it, including plenary sessions at LSFMM.  As a filesystem
developer, you must want to not know about it at this point.

> It's straightforward enough to read all contents for a larger folio,
> it's no different to subpage handling.
> 
> But what will happen if some writes happened to that larger folio?
> Do MM layer detects that and split the folios? Or the fs has to go the
> subpage routine (with an extra structure recording all the subpage flags
> bitmap)?

Entirely up to the filesystem.  It would help if btrfs used the same
terminology as the rest of the filesystems instead of inventing its own
"subpage" thing.  As far as I can tell, "subpage" means "fs block size",
but maybe it has a different meaning that I haven't ascertained.

Tracking dirtiness on a per-folio basis does not seem to be good enough.
Various people have workloads that regress in performance if you do
that.  So having some data structure attached to folio->private which
tracks dirtiness on a per-fs-block basis works pretty well.  iomap also
tracks the uptodate bit on a per-fs-block basis, but I'm less convinced
that's necessary.

I have no idea why btrfs thinks it needs to track writeback, ordered,
checked and locked in a bitmap.  Those make no sense to me.  But they
make no sense to me if you're support a 4KiB filesystem on a machine
with a 64KiB PAGE_SIZE, not just in the context of "larger folios".
Writeback is something the VM tells you to do; why do you need to tag
individual blocks for writeback?


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Qu Wenruo via Linux-f2fs-devel]

在 2024/8/22 21:37, Matthew Wilcox 写道:
> On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
>> 在 2024/8/22 12:35, Matthew Wilcox 写道:
>>>> -	while (cur < page_start + PAGE_SIZE) {
>>>> +	while (cur < folio_start + PAGE_SIZE) {
>>>
>>> Presumably we want to support large folios in btrfs at some point?
>>
>> Yes, and we're already working towards that direction.
>>
>>> I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
>>> be a bit of a regression for btrfs if it doesn't have large folio
>>> support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?
>>
>> AFAIK we're only going to support larger folios to support larger than
>> PAGE_SIZE sector size so far.
>
> Why do you not want the performance gains from using larger folios?
>
>> So every folio is still in a fixed size (sector size, >= PAGE_SIZE).
>>
>> Not familiar with transparent huge page, I thought transparent huge page
>> is transparent to fs.
>>
>> Or do we need some special handling?
>> My uneducated guess is, we will get a larger folio passed to readpage
>> call back directly?
>
> Why do you choose to remain uneducated?  It's not like I've been keeping
> all of this to myself for the past five years.  I've given dozens of
> presentations on it, including plenary sessions at LSFMM.  As a filesystem
> developer, you must want to not know about it at this point.
>
>> It's straightforward enough to read all contents for a larger folio,
>> it's no different to subpage handling.
>>
>> But what will happen if some writes happened to that larger folio?
>> Do MM layer detects that and split the folios? Or the fs has to go the
>> subpage routine (with an extra structure recording all the subpage flags
>> bitmap)?
>
> Entirely up to the filesystem.  It would help if btrfs used the same
> terminology as the rest of the filesystems instead of inventing its own
> "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
> but maybe it has a different meaning that I haven't ascertained.

Then tell me the correct terminology to describe fs block size smaller
than page size in the first place.

"fs block size" is not good enough, we want a terminology to describe
"fs block size" smaller than page size.

>
> Tracking dirtiness on a per-folio basis does not seem to be good enough.
> Various people have workloads that regress in performance if you do
> that.  So having some data structure attached to folio->private which
> tracks dirtiness on a per-fs-block basis works pretty well.  iomap also
> tracks the uptodate bit on a per-fs-block basis, but I'm less convinced
> that's necessary.
>
> I have no idea why btrfs thinks it needs to track writeback, ordered,
> checked and locked in a bitmap.  Those make no sense to me.  But they
> make no sense to me if you're support a 4KiB filesystem on a machine
> with a 64KiB PAGE_SIZE, not just in the context of "larger folios".
> Writeback is something the VM tells you to do; why do you need to tag
> individual blocks for writeback?

Because there are cases where btrfs needs to only write back part of the
folio independently.

And especially for mixing compression and non-compression writes inside
a page, e.g:

       0     16K     32K     48K      64K
       |//|          |///////|
          4K

In above case, if we need to writeback above page with 4K sector size,
then the first 4K is not suitable for compression (result will still
take a full 4K block), while the range [32K, 48K) will be compressed.

In that case, [0, 4K) range will be submitted directly for IO.
Meanwhile [32K, 48) will be submitted for compression in antoher wq.
(Or time consuming compression will delay the writeback of the remaining
pages)

This means the dirty/writeback flags will have a different timing to be
changed.

I think compression is no long a btrfs exclusive feature, thus this
should be obvious?

Thanks,
Qu


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Qu Wenruo via Linux-f2fs-devel]

在 2024/8/23 07:55, Qu Wenruo 写道:
>
>
> 在 2024/8/22 21:37, Matthew Wilcox 写道:
>> On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
>>> 在 2024/8/22 12:35, Matthew Wilcox 写道:
>>>>> -    while (cur < page_start + PAGE_SIZE) {
>>>>> +    while (cur < folio_start + PAGE_SIZE) {
>>>>
>>>> Presumably we want to support large folios in btrfs at some point?
>>>
>>> Yes, and we're already working towards that direction.
>>>
>>>> I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
>>>> be a bit of a regression for btrfs if it doesn't have large folio
>>>> support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?
>>>
>>> AFAIK we're only going to support larger folios to support larger than
>>> PAGE_SIZE sector size so far.
>>
>> Why do you not want the performance gains from using larger folios?
>>
>>> So every folio is still in a fixed size (sector size, >= PAGE_SIZE).
>>>
>>> Not familiar with transparent huge page, I thought transparent huge page
>>> is transparent to fs.
>>>
>>> Or do we need some special handling?
>>> My uneducated guess is, we will get a larger folio passed to readpage
>>> call back directly?
>>
>> Why do you choose to remain uneducated?  It's not like I've been keeping
>> all of this to myself for the past five years.  I've given dozens of
>> presentations on it, including plenary sessions at LSFMM.  As a
>> filesystem
>> developer, you must want to not know about it at this point.
>>
>>> It's straightforward enough to read all contents for a larger folio,
>>> it's no different to subpage handling.
>>>
>>> But what will happen if some writes happened to that larger folio?
>>> Do MM layer detects that and split the folios? Or the fs has to go the
>>> subpage routine (with an extra structure recording all the subpage flags
>>> bitmap)?
>>
>> Entirely up to the filesystem.  It would help if btrfs used the same
>> terminology as the rest of the filesystems instead of inventing its own
>> "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
>> but maybe it has a different meaning that I haven't ascertained.
>
> Then tell me the correct terminology to describe fs block size smaller
> than page size in the first place.
>
> "fs block size" is not good enough, we want a terminology to describe
> "fs block size" smaller than page size.
>
>>
>> Tracking dirtiness on a per-folio basis does not seem to be good enough.
>> Various people have workloads that regress in performance if you do
>> that.  So having some data structure attached to folio->private which
>> tracks dirtiness on a per-fs-block basis works pretty well.  iomap also
>> tracks the uptodate bit on a per-fs-block basis, but I'm less convinced
>> that's necessary.
>>
>> I have no idea why btrfs thinks it needs to track writeback, ordered,
>> checked and locked in a bitmap.  Those make no sense to me.  But they
>> make no sense to me if you're support a 4KiB filesystem on a machine
>> with a 64KiB PAGE_SIZE, not just in the context of "larger folios".
>> Writeback is something the VM tells you to do; why do you need to tag
>> individual blocks for writeback?
>
> Because there are cases where btrfs needs to only write back part of the
> folio independently.
>
> And especially for mixing compression and non-compression writes inside
> a page, e.g:
>
>        0     16K     32K     48K      64K
>        |//|          |///////|
>           4K
>
> In above case, if we need to writeback above page with 4K sector size,
> then the first 4K is not suitable for compression (result will still
> take a full 4K block), while the range [32K, 48K) will be compressed.
>
> In that case, [0, 4K) range will be submitted directly for IO.
> Meanwhile [32K, 48) will be submitted for compression in antoher wq.
> (Or time consuming compression will delay the writeback of the remaining
> pages)
>
> This means the dirty/writeback flags will have a different timing to be
> changed.

Just in case if you mean using an atomic to trace the writeback/lock
progress, then it's possible to go that path, but for now it's not space
efficient.

For 16 blocks per page case (4K sectorsize 64K page size), each atomic
takes 4 bytes while a bitmap only takes 2 bytes.

And for 4K sectorsize 16K page size case, it's worse and btrfs compact
all the bitmaps into a larger one to save more space, while each atomic
still takes 4 bytes.

Thanks,
Qu

>
> I think compression is no long a btrfs exclusive feature, thus this
> should be obvious?
>
> Thanks,
> Qu
>


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Josef Bacik]

On Thu, Aug 22, 2024 at 01:07:52PM +0100, Matthew Wilcox wrote:
> On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > 在 2024/8/22 12:35, Matthew Wilcox 写道:
> > > > -	while (cur < page_start + PAGE_SIZE) {
> > > > +	while (cur < folio_start + PAGE_SIZE) {
> > > 
> > > Presumably we want to support large folios in btrfs at some point?
> > 
> > Yes, and we're already working towards that direction.
> > 
> > > I certainly want to remove CONFIG_READ_ONLY_THP_FOR_FS soon and that'll
> > > be a bit of a regression for btrfs if it doesn't have large folio
> > > support.  So shouldn't we also s/PAGE_SIZE/folio_size(folio)/ ?
> > 
> > AFAIK we're only going to support larger folios to support larger than
> > PAGE_SIZE sector size so far.
> 
> Why do you not want the performance gains from using larger folios?
> 
> > So every folio is still in a fixed size (sector size, >= PAGE_SIZE).
> > 
> > Not familiar with transparent huge page, I thought transparent huge page
> > is transparent to fs.
> > 
> > Or do we need some special handling?
> > My uneducated guess is, we will get a larger folio passed to readpage
> > call back directly?
> 
> Why do you choose to remain uneducated?  It's not like I've been keeping
> all of this to myself for the past five years.  I've given dozens of
> presentations on it, including plenary sessions at LSFMM.  As a filesystem
> developer, you must want to not know about it at this point.
> 

Or, a more charitable read, is that this particular developer has never been to
LSFMMBPF/Plumbers/anywhere you've given a talk.

This stuff is complicated, I don't even know what's going on half the time, much
less a developer who exclusively works on btrfs internals.

There's a lot of things to know in this space, we can't all know what's going on
in every corner.

As for the topic at hand, I'm moving us in the direction of an iomap conversion
so we can have the large folio support, regardless of the underlying
sectorsize/metadata block size.  Unfortunately there's a lot of fundamental
changes that need to be made to facilitate that, and those are going to take
some time to test and validate to make sure we didn't break anything.  In the
meantime we're going to be in this weird limbo states while I tackle the
individual problem areas.

My priorities are split between getting this to work and fuse improvements to
eventually no longer need to have file systems in the kernel to avoid all this
in general, so it's going to be spurty, but I hope to have this work done by the
next LSFMMBPF.  Thanks,

Josef


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Matthew Wilcox]

On Fri, Aug 23, 2024 at 11:43:41AM +0930, Qu Wenruo wrote:
> 在 2024/8/23 07:55, Qu Wenruo 写道:
> > 在 2024/8/22 21:37, Matthew Wilcox 写道:
> > > On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > > > But what will happen if some writes happened to that larger folio?
> > > > Do MM layer detects that and split the folios? Or the fs has to go the
> > > > subpage routine (with an extra structure recording all the subpage flags
> > > > bitmap)?
> > > 
> > > Entirely up to the filesystem.  It would help if btrfs used the same
> > > terminology as the rest of the filesystems instead of inventing its own
> > > "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
> > > but maybe it has a different meaning that I haven't ascertained.
> > 
> > Then tell me the correct terminology to describe fs block size smaller
> > than page size in the first place.
> > 
> > "fs block size" is not good enough, we want a terminology to describe
> > "fs block size" smaller than page size.

Oh dear.  btrfs really has corrupted your brain.  Here's the terminology
used in the rest of Linux:

SECTOR_SIZE.  Fixed at 512 bytes.  This is the unit used to communicate
with the block layer.  It has no real meaning, other than Linux doesn't
support block devices with 128 and 256 byte sector sizes (I have used
such systems, but not in the last 30 years).

LBA size.  This is the unit that the block layer uses to communicate
with the block device.  Must be at least SECTOR_SIZE.  I/O cannot be
performed in smaller chunks than this.

Physical block size.  This is the unit that the device advertises as
its efficient minimum size.  I/Os smaller than this / not aligned to
this will probably incur a performance penalty as the device will need
to do a read-modify-write cycle.

fs block size.  Known as s_blocksize or i_blocksize.  Must be a multiple
of LBA size, but may be smaller than physical block size.  Files are
allocated in multiples of this unit.

PAGE_SIZE.  Unit that memory can be mapped in.  This applies to both
userspace mapping of files as well as calls to kmap_local_*().

folio size.  The size that the page cache has decided to manage this
chunk of the file in.  A multiple of PAGE_SIZE.


I've mostly listed this in smallest to largest.  The relationships that
must be true:

SS <= LBA <= Phys
LBA <= fsb
PS <= folio
fsb <= folio

ocfs2 supports fsb > PAGE_SIZE, but this is a rarity.  Most filesystems
require fsb <= PAGE_SIZE.

Filesystems like UFS also support a fragment size which is less than fs
block size.  It's kind of like tail packing.  Anyway, that's internal to
the filesystem and not exposed to the VFS.

> > > I have no idea why btrfs thinks it needs to track writeback, ordered,
> > > checked and locked in a bitmap.  Those make no sense to me.  But they
> > > make no sense to me if you're support a 4KiB filesystem on a machine
> > > with a 64KiB PAGE_SIZE, not just in the context of "larger folios".
> > > Writeback is something the VM tells you to do; why do you need to tag
> > > individual blocks for writeback?
> > 
> > Because there are cases where btrfs needs to only write back part of the
> > folio independently.

iomap manages to do this with only tracking per-block dirty bits.

> > And especially for mixing compression and non-compression writes inside
> > a page, e.g:
> > 
> >        0     16K     32K     48K      64K
> >        |//|          |///////|
> >           4K
> > 
> > In above case, if we need to writeback above page with 4K sector size,
> > then the first 4K is not suitable for compression (result will still
> > take a full 4K block), while the range [32K, 48K) will be compressed.
> > 
> > In that case, [0, 4K) range will be submitted directly for IO.
> > Meanwhile [32K, 48) will be submitted for compression in antoher wq.
> > (Or time consuming compression will delay the writeback of the remaining
> > pages)
> > 
> > This means the dirty/writeback flags will have a different timing to be
> > changed.
> 
> Just in case if you mean using an atomic to trace the writeback/lock
> progress, then it's possible to go that path, but for now it's not space
> efficient.
> 
> For 16 blocks per page case (4K sectorsize 64K page size), each atomic
> takes 4 bytes while a bitmap only takes 2 bytes.
> 
> And for 4K sectorsize 16K page size case, it's worse and btrfs compact
> all the bitmaps into a larger one to save more space, while each atomic
> still takes 4 bytes.

Sure, but it doesn't scale up well.  And it's kind of irrelevant whether
you occupy 2 or 4 bytes at the low end because you're allocating all
this through slab, so you get rounded to 8 bytes anyway.
iomap_folio_state currently occupies 12 bytes + 2 bits per block.  So
for a 16 block folio (4k in 64k), that's 32 bits for a total of 16
bytes.  For a 2MB folio on a 4kB block size fs, that's 1024 bits for
a total of 140 bytes (rounded to 192 bytes by slab).

Hm, it might be worth adding a kmalloc-160, we'd get 25 objects per 4KiB
page instead of 21 192-byte objects ...



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[Josef Bacik]

On Thu, Aug 22, 2024 at 09:37:00AM +0800, Li Zetao wrote:
> Hi all,
> 
> In btrfs, because there are some interfaces that do not use folio,
> there is page-folio-page mutual conversion. This patch set should
> clean up folio-page conversion as much as possible and use folio
> directly to reduce invalid conversions.
> 
> This patch set starts with the rectification of function parameters,
> using folio as parameters directly. And some of those functions have
> already been converted to folio internally, so this part has little
> impact. 
> 
> I have tested with fsstress more than 10 hours, and no problems were
> found. For the convenience of reviewing, I try my best to only modify
> a single interface in each patch.
> 
> Josef also worked on converting pages to folios, and this patch set was
> inspired by him:
> https://lore.kernel.org/all/cover.1722022376.git.josef@toxicpanda.com/
> 

This looks good, I'm running it through the CI.  If that comes out clean then
I'll put my reviewed-by on it and push it to our for-next branch.  The CI run
can be seen here

https://github.com/btrfs/linux/actions/runs/10531503734

Don't worry if you see errors on the zoned run or the RST run, Johannes is
running down the RST stuff and I need to sit down and figure out what's going on
with zoned.  If anything else fails I'll look at it to see if it's legit or not.
Thanks,

Josef


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[Josef Bacik]

On Fri, Aug 23, 2024 at 03:50:51PM -0400, Josef Bacik wrote:
> On Thu, Aug 22, 2024 at 09:37:00AM +0800, Li Zetao wrote:
> > Hi all,
> > 
> > In btrfs, because there are some interfaces that do not use folio,
> > there is page-folio-page mutual conversion. This patch set should
> > clean up folio-page conversion as much as possible and use folio
> > directly to reduce invalid conversions.
> > 
> > This patch set starts with the rectification of function parameters,
> > using folio as parameters directly. And some of those functions have
> > already been converted to folio internally, so this part has little
> > impact. 
> > 
> > I have tested with fsstress more than 10 hours, and no problems were
> > found. For the convenience of reviewing, I try my best to only modify
> > a single interface in each patch.
> > 
> > Josef also worked on converting pages to folios, and this patch set was
> > inspired by him:
> > https://lore.kernel.org/all/cover.1722022376.git.josef@toxicpanda.com/
> > 
> 
> This looks good, I'm running it through the CI.  If that comes out clean then
> I'll put my reviewed-by on it and push it to our for-next branch.  The CI run
> can be seen here
> 
> https://github.com/btrfs/linux/actions/runs/10531503734
> 

Looks like the compression stuff panic'ed, the run has to finish before it
collects the dmesg so IDK where it failed yet, but I'd go over the compression
stuff again to see if you can spot it.  When the whole run finishes there will
be test artifacts you can get to.  If you don't have permissions (I honestly
don't know how the artifacts permission stuff works) then no worries, I'll grab
it in the morning and send you the test and dmesg of what fell over.  Thanks,

Josef


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Qu Wenruo via Linux-f2fs-devel]

在 2024/8/24 01:08, Matthew Wilcox 写道:
> On Fri, Aug 23, 2024 at 11:43:41AM +0930, Qu Wenruo wrote:
>> 在 2024/8/23 07:55, Qu Wenruo 写道:
>>> 在 2024/8/22 21:37, Matthew Wilcox 写道:
>>>> On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
>>>>> But what will happen if some writes happened to that larger folio?
>>>>> Do MM layer detects that and split the folios? Or the fs has to go the
>>>>> subpage routine (with an extra structure recording all the subpage flags
>>>>> bitmap)?
>>>>
>>>> Entirely up to the filesystem.  It would help if btrfs used the same
>>>> terminology as the rest of the filesystems instead of inventing its own
>>>> "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
>>>> but maybe it has a different meaning that I haven't ascertained.
>>>
>>> Then tell me the correct terminology to describe fs block size smaller
>>> than page size in the first place.
>>>
>>> "fs block size" is not good enough, we want a terminology to describe
>>> "fs block size" smaller than page size.
>
> Oh dear.  btrfs really has corrupted your brain.  Here's the terminology
> used in the rest of Linux:
>
> SECTOR_SIZE.  Fixed at 512 bytes.  This is the unit used to communicate
> with the block layer.  It has no real meaning, other than Linux doesn't
> support block devices with 128 and 256 byte sector sizes (I have used
> such systems, but not in the last 30 years).
>
> LBA size.  This is the unit that the block layer uses to communicate
> with the block device.  Must be at least SECTOR_SIZE.  I/O cannot be
> performed in smaller chunks than this.
>
> Physical block size.  This is the unit that the device advertises as
> its efficient minimum size.  I/Os smaller than this / not aligned to
> this will probably incur a performance penalty as the device will need
> to do a read-modify-write cycle.
>
> fs block size.  Known as s_blocksize or i_blocksize.  Must be a multiple
> of LBA size, but may be smaller than physical block size.  Files are
> allocated in multiples of this unit.
>
> PAGE_SIZE.  Unit that memory can be mapped in.  This applies to both
> userspace mapping of files as well as calls to kmap_local_*().
>
> folio size.  The size that the page cache has decided to manage this
> chunk of the file in.  A multiple of PAGE_SIZE.
>
>
> I've mostly listed this in smallest to largest.  The relationships that
> must be true:
>
> SS <= LBA <= Phys
> LBA <= fsb
> PS <= folio
> fsb <= folio
>
> ocfs2 supports fsb > PAGE_SIZE, but this is a rarity.  Most filesystems
> require fsb <= PAGE_SIZE.
>
> Filesystems like UFS also support a fragment size which is less than fs
> block size.  It's kind of like tail packing.  Anyway, that's internal to
> the filesystem and not exposed to the VFS.

I know all these things, the terminology I need is a short one to
describe fsb < PAGE_SIZE case.

So far, in the fs' realm, "subpage" (sub page sized block size) is the
shortest and simplest one.

Sure you will get confused with a "subpage" range  inside a page, but
that's because you're mostly working in the MM layer.

So please give me a better alternative to describe exact "fbs <
PAGE_SIZE" case.
Or it's just complaining without any constructive advice.

>
>>>> I have no idea why btrfs thinks it needs to track writeback, ordered,
>>>> checked and locked in a bitmap.  Those make no sense to me.  But they
>>>> make no sense to me if you're support a 4KiB filesystem on a machine
>>>> with a 64KiB PAGE_SIZE, not just in the context of "larger folios".
>>>> Writeback is something the VM tells you to do; why do you need to tag
>>>> individual blocks for writeback?
>>>
>>> Because there are cases where btrfs needs to only write back part of the
>>> folio independently.
>
> iomap manages to do this with only tracking per-block dirty bits.

Well, does iomap support asynchronous compression?

This proves the point of Josef, different people have different focus,
please do not assume everyone knows the realm you're doing, nor assume
there will always be a one-fit-all solution.

>
>>> And especially for mixing compression and non-compression writes inside
>>> a page, e.g:
>>>
>>>         0     16K     32K     48K      64K
>>>         |//|          |///////|
>>>            4K
>>>
>>> In above case, if we need to writeback above page with 4K sector size,
>>> then the first 4K is not suitable for compression (result will still
>>> take a full 4K block), while the range [32K, 48K) will be compressed.
>>>
>>> In that case, [0, 4K) range will be submitted directly for IO.
>>> Meanwhile [32K, 48) will be submitted for compression in antoher wq.
>>> (Or time consuming compression will delay the writeback of the remaining
>>> pages)
>>>
>>> This means the dirty/writeback flags will have a different timing to be
>>> changed.
>>
>> Just in case if you mean using an atomic to trace the writeback/lock
>> progress, then it's possible to go that path, but for now it's not space
>> efficient.
>>
>> For 16 blocks per page case (4K sectorsize 64K page size), each atomic
>> takes 4 bytes while a bitmap only takes 2 bytes.
>>
>> And for 4K sectorsize 16K page size case, it's worse and btrfs compact
>> all the bitmaps into a larger one to save more space, while each atomic
>> still takes 4 bytes.
>
> Sure, but it doesn't scale up well.  And it's kind of irrelevant whether
> you occupy 2 or 4 bytes at the low end because you're allocating all
> this through slab, so you get rounded to 8 bytes anyway.
> iomap_folio_state currently occupies 12 bytes + 2 bits per block.  So
> for a 16 block folio (4k in 64k), that's 32 bits for a total of 16
> bytes.  For a 2MB folio on a 4kB block size fs, that's 1024 bits for
> a total of 140 bytes (rounded to 192 bytes by slab).

Yes it's not scalable for all folio sizes, but the turning point is 32
bits, which means 128K folio for 4K page sized system.
Since the folio code already consider order > 3 as costly, I'm totally
fine to sacrifice the higher order ones, not the other way around.

Although the real determining factor is the real world distribution of
folio sizes.

But for now, since btrfs only supports 4K block size with 64K/16K page
size, it's still a win for us.

Another point of the bitmap is, it helps (at least for me) a lot for
debugging, but that can always be hidden behind some debug flag.


I'm not denying the possibility to fully migrate to the iomap way, but
that will need a lot of extra work like clean up the cow_fixup thing to
reduce the extra page flag tracking first.
(That always causes a lot of discussion but seldomly leads to patches)

Thanks,
Qu
>
> Hm, it might be worth adding a kmalloc-160, we'd get 25 objects per 4KiB
> page instead of 21 192-byte objects ...
>
>


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[Josef Bacik]

On Fri, Aug 23, 2024 at 05:15:22PM -0400, Josef Bacik wrote:
> On Fri, Aug 23, 2024 at 03:50:51PM -0400, Josef Bacik wrote:
> > On Thu, Aug 22, 2024 at 09:37:00AM +0800, Li Zetao wrote:
> > > Hi all,
> > > 
> > > In btrfs, because there are some interfaces that do not use folio,
> > > there is page-folio-page mutual conversion. This patch set should
> > > clean up folio-page conversion as much as possible and use folio
> > > directly to reduce invalid conversions.
> > > 
> > > This patch set starts with the rectification of function parameters,
> > > using folio as parameters directly. And some of those functions have
> > > already been converted to folio internally, so this part has little
> > > impact. 
> > > 
> > > I have tested with fsstress more than 10 hours, and no problems were
> > > found. For the convenience of reviewing, I try my best to only modify
> > > a single interface in each patch.
> > > 
> > > Josef also worked on converting pages to folios, and this patch set was
> > > inspired by him:
> > > https://lore.kernel.org/all/cover.1722022376.git.josef@toxicpanda.com/
> > > 
> > 
> > This looks good, I'm running it through the CI.  If that comes out clean then
> > I'll put my reviewed-by on it and push it to our for-next branch.  The CI run
> > can be seen here
> > 
> > https://github.com/btrfs/linux/actions/runs/10531503734
> > 
> 
> Looks like the compression stuff panic'ed, the run has to finish before it
> collects the dmesg so IDK where it failed yet, but I'd go over the compression
> stuff again to see if you can spot it.  When the whole run finishes there will
> be test artifacts you can get to.  If you don't have permissions (I honestly
> don't know how the artifacts permission stuff works) then no worries, I'll grab
> it in the morning and send you the test and dmesg of what fell over.  Thanks,
> 

They all fell over, so I suggest running fstests against your series before you
resend.  btrfs/069 paniced on one machine, btrfs/060 paniced on one machine.
None of the machines passsed without panicing.  Thanks,

Josef


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Josef Bacik]

On Fri, Aug 23, 2024 at 04:38:27PM +0100, Matthew Wilcox wrote:
> On Fri, Aug 23, 2024 at 11:43:41AM +0930, Qu Wenruo wrote:
> > 在 2024/8/23 07:55, Qu Wenruo 写道:
> > > 在 2024/8/22 21:37, Matthew Wilcox 写道:
> > > > On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > > > > But what will happen if some writes happened to that larger folio?
> > > > > Do MM layer detects that and split the folios? Or the fs has to go the
> > > > > subpage routine (with an extra structure recording all the subpage flags
> > > > > bitmap)?
> > > > 
> > > > Entirely up to the filesystem.  It would help if btrfs used the same
> > > > terminology as the rest of the filesystems instead of inventing its own
> > > > "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
> > > > but maybe it has a different meaning that I haven't ascertained.
> > > 
> > > Then tell me the correct terminology to describe fs block size smaller
> > > than page size in the first place.
> > > 
> > > "fs block size" is not good enough, we want a terminology to describe
> > > "fs block size" smaller than page size.
> 
> Oh dear.  btrfs really has corrupted your brain.  Here's the terminology
> used in the rest of Linux:

This isn't necessary commentary, this gives the impression that we're
wrong/stupid/etc.  We're all in this community together, having public, negative
commentary like this is unnecessary, and frankly contributes to my growing
desire/priorities to shift most of my development outside of the kernel
community.  And if somebody with my experience and history in this community is
becoming more and more disillusioned with this work and making serious efforts
to extricate themselves from the project, then what does that say about our
ability to bring in new developers?  Thanks,

Josef


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Matthew Wilcox]

On Mon, Aug 26, 2024 at 10:13:01AM -0400, Josef Bacik wrote:
> On Fri, Aug 23, 2024 at 04:38:27PM +0100, Matthew Wilcox wrote:
> > On Fri, Aug 23, 2024 at 11:43:41AM +0930, Qu Wenruo wrote:
> > > 在 2024/8/23 07:55, Qu Wenruo 写道:
> > > > 在 2024/8/22 21:37, Matthew Wilcox 写道:
> > > > > On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > > > > > But what will happen if some writes happened to that larger folio?
> > > > > > Do MM layer detects that and split the folios? Or the fs has to go the
> > > > > > subpage routine (with an extra structure recording all the subpage flags
> > > > > > bitmap)?
> > > > > 
> > > > > Entirely up to the filesystem.  It would help if btrfs used the same
> > > > > terminology as the rest of the filesystems instead of inventing its own
> > > > > "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
> > > > > but maybe it has a different meaning that I haven't ascertained.
> > > > 
> > > > Then tell me the correct terminology to describe fs block size smaller
> > > > than page size in the first place.
> > > > 
> > > > "fs block size" is not good enough, we want a terminology to describe
> > > > "fs block size" smaller than page size.
> > 
> > Oh dear.  btrfs really has corrupted your brain.  Here's the terminology
> > used in the rest of Linux:
> 
> This isn't necessary commentary, this gives the impression that we're
> wrong/stupid/etc.  We're all in this community together, having public, negative
> commentary like this is unnecessary, and frankly contributes to my growing
> desire/priorities to shift most of my development outside of the kernel
> community.  And if somebody with my experience and history in this community is
> becoming more and more disillusioned with this work and making serious efforts
> to extricate themselves from the project, then what does that say about our
> ability to bring in new developers?  Thanks,

You know what?  I'm disillusioned too.  It's been over two and a half
years since folios were added (v5.16 was the first release with folios).
I knew it would be a long project (I was anticipating five years).
I was expecting to have to slog through all the old unmaintained crap
filesystems doing minimal conversions.  What I wasn't expecting was for
all the allegedly maintained filesystems to sit on their fucking hands and
ignore it as long as possible.  The biggest pains right now are btrfs,
ceph and f2fs, all of which have people who are paid to work on them!
I had to do ext4 largely myself.

Some filesystems have been great.  XFS worked with me as I did that
filesystem first.  nfs took care of their own code.  Dave Howells has
done most of the other network filesystems.  Many other people have
also helped.

But we can't even talk to each other unless we agree on what words mean.
And btrfs inventing its own terminology for things which already exist
in other filesystems is extremely unhelpful.

We need to remove the temporary hack that is CONFIG_READ_ONLY_THP_FOR_FS.
That went in with the understanding that filesystems that mattered would
add large folio support.  When I see someone purporting to represent
btrfs say "Oh, we're not going to do that", that's a breach of trust.

When I'm accused of not understanding things from the filesystem
perspective, that's just a lie.  I have 192 commits in fs/ between 6.6
and 6.10 versus 160 in mm/ (346 commits in both combined, so 6 commits
are double-counted because they touch both).  This whole project has
been filesystem-centric from the beginning.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Josef Bacik]

On Mon, Aug 26, 2024 at 05:56:01PM +0100, Matthew Wilcox wrote:
> On Mon, Aug 26, 2024 at 10:13:01AM -0400, Josef Bacik wrote:
> > On Fri, Aug 23, 2024 at 04:38:27PM +0100, Matthew Wilcox wrote:
> > > On Fri, Aug 23, 2024 at 11:43:41AM +0930, Qu Wenruo wrote:
> > > > 在 2024/8/23 07:55, Qu Wenruo 写道:
> > > > > 在 2024/8/22 21:37, Matthew Wilcox 写道:
> > > > > > On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > > > > > > But what will happen if some writes happened to that larger folio?
> > > > > > > Do MM layer detects that and split the folios? Or the fs has to go the
> > > > > > > subpage routine (with an extra structure recording all the subpage flags
> > > > > > > bitmap)?
> > > > > > 
> > > > > > Entirely up to the filesystem.  It would help if btrfs used the same
> > > > > > terminology as the rest of the filesystems instead of inventing its own
> > > > > > "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
> > > > > > but maybe it has a different meaning that I haven't ascertained.
> > > > > 
> > > > > Then tell me the correct terminology to describe fs block size smaller
> > > > > than page size in the first place.
> > > > > 
> > > > > "fs block size" is not good enough, we want a terminology to describe
> > > > > "fs block size" smaller than page size.
> > > 
> > > Oh dear.  btrfs really has corrupted your brain.  Here's the terminology
> > > used in the rest of Linux:
> > 
> > This isn't necessary commentary, this gives the impression that we're
> > wrong/stupid/etc.  We're all in this community together, having public, negative
> > commentary like this is unnecessary, and frankly contributes to my growing
> > desire/priorities to shift most of my development outside of the kernel
> > community.  And if somebody with my experience and history in this community is
> > becoming more and more disillusioned with this work and making serious efforts
> > to extricate themselves from the project, then what does that say about our
> > ability to bring in new developers?  Thanks,
> 
> You know what?  I'm disillusioned too.  It's been over two and a half
> years since folios were added (v5.16 was the first release with folios).
> I knew it would be a long project (I was anticipating five years).
> I was expecting to have to slog through all the old unmaintained crap
> filesystems doing minimal conversions.  What I wasn't expecting was for
> all the allegedly maintained filesystems to sit on their fucking hands and
> ignore it as long as possible.  The biggest pains right now are btrfs,
> ceph and f2fs, all of which have people who are paid to work on them!
> I had to do ext4 largely myself.
> 
> Some filesystems have been great.  XFS worked with me as I did that
> filesystem first.  nfs took care of their own code.  Dave Howells has
> done most of the other network filesystems.  Many other people have
> also helped.
> 
> But we can't even talk to each other unless we agree on what words mean.
> And btrfs inventing its own terminology for things which already exist
> in other filesystems is extremely unhelpful.
> 
> We need to remove the temporary hack that is CONFIG_READ_ONLY_THP_FOR_FS.
> That went in with the understanding that filesystems that mattered would
> add large folio support.  When I see someone purporting to represent
> btrfs say "Oh, we're not going to do that", that's a breach of trust.
> 
> When I'm accused of not understanding things from the filesystem
> perspective, that's just a lie.  I have 192 commits in fs/ between 6.6
> and 6.10 versus 160 in mm/ (346 commits in both combined, so 6 commits
> are double-counted because they touch both).  This whole project has
> been filesystem-centric from the beginning.

I'm not talking about the pace of change, I'm talking about basic, professional
communication standards.  Being frustrated is one thing, taking it out on a
developer or a project in a public forum is another.  Thanks,

Josef


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[Li Zetao via Linux-f2fs-devel]

在 2024/8/26 22:08, Josef Bacik 写道:
> On Fri, Aug 23, 2024 at 05:15:22PM -0400, Josef Bacik wrote:
>> On Fri, Aug 23, 2024 at 03:50:51PM -0400, Josef Bacik wrote:
>>> On Thu, Aug 22, 2024 at 09:37:00AM +0800, Li Zetao wrote:
>>>> Hi all,
>>>>
>>>> In btrfs, because there are some interfaces that do not use folio,
>>>> there is page-folio-page mutual conversion. This patch set should
>>>> clean up folio-page conversion as much as possible and use folio
>>>> directly to reduce invalid conversions.
>>>>
>>>> This patch set starts with the rectification of function parameters,
>>>> using folio as parameters directly. And some of those functions have
>>>> already been converted to folio internally, so this part has little
>>>> impact.
>>>>
>>>> I have tested with fsstress more than 10 hours, and no problems were
>>>> found. For the convenience of reviewing, I try my best to only modify
>>>> a single interface in each patch.
>>>>
>>>> Josef also worked on converting pages to folios, and this patch set was
>>>> inspired by him:
>>>> https://lore.kernel.org/all/cover.1722022376.git.josef@toxicpanda.com/
>>>>
>>>
>>> This looks good, I'm running it through the CI.  If that comes out clean then
>>> I'll put my reviewed-by on it and push it to our for-next branch.  The CI run
>>> can be seen here
>>>
>>> https://github.com/btrfs/linux/actions/runs/10531503734
>>>
>>
>> Looks like the compression stuff panic'ed, the run has to finish before it
>> collects the dmesg so IDK where it failed yet, but I'd go over the compression
>> stuff again to see if you can spot it.  When the whole run finishes there will
>> be test artifacts you can get to.  If you don't have permissions (I honestly
>> don't know how the artifacts permission stuff works) then no worries, I'll grab
>> it in the morning and send you the test and dmesg of what fell over.  Thanks,
>>
> 
> They all fell over, so I suggest running fstests against your series before you
> resend.  btrfs/069 paniced on one machine, btrfs/060 paniced on one machine.
> None of the machines passsed without panicing.  Thanks,
> 
Thank you for your test. When btrfs/060 and btrfs/069 failed due to my 
carelessness, Dan has issued a patch[1] to fix it. After applying his 
patch, it was still found that 3 test cases reported errors. I reverted 
my patchset and the error still persists, so the errors may not be 
caused by my patch. Below is the test log:

   Failures: btrfs/012 btrfs/249 btrfs/284
   Failed 3 of 322 tests

My xfstests project is forked from https://github.com/kdave/xfstests.git

> Josef
> 

[1]: 
https://lore.kernel.org/linux-btrfs/20240827153739.GY25962@twin.jikos.cz/T/#m3f3e28dad05a9c8385a72f5503a5b9c130b44c04


Thanks,
Li Zetao.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] [PATCH -next 00/14] btrfs: Cleaned up folio->page conversion

[patchwork-bot+f2fs--- via Linux-f2fs-devel]

Hello:

This series was applied to jaegeuk/f2fs.git (dev)
by David Sterba <dsterba@suse.com>:

On Thu, 22 Aug 2024 09:37:00 +0800 you wrote:
> Hi all,
> 
> In btrfs, because there are some interfaces that do not use folio,
> there is page-folio-page mutual conversion. This patch set should
> clean up folio-page conversion as much as possible and use folio
> directly to reduce invalid conversions.
> 
> [...]

Here is the summary with links:
  - [f2fs-dev,01/14] btrfs: convert clear_page_extent_mapped() to take a folio
    (no matching commit)
  - [f2fs-dev,02/14] btrfs: convert get_next_extent_buffer() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/d4aeb5f7a7e6
  - [f2fs-dev,03/14] btrfs: convert try_release_subpage_extent_buffer() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/0145aa38cb39
  - [f2fs-dev,04/14] btrfs: convert try_release_extent_buffer() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/b8ae2bfa685f
  - [f2fs-dev,05/14] btrfs: convert read_key_bytes() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/884937793db5
  - [f2fs-dev,06/14] btrfs: convert submit_eb_subpage() to take a folio
    (no matching commit)
  - [f2fs-dev,07/14] btrfs: convert submit_eb_page() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/08dd8507b116
  - [f2fs-dev,08/14] btrfs: convert try_release_extent_state() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/dd0a8df45566
  - [f2fs-dev,09/14] btrfs: convert try_release_extent_mapping() to take a folio
    (no matching commit)
  - [f2fs-dev,10/14] btrfs: convert zlib_decompress() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/54c78d497b38
  - [f2fs-dev,11/14] btrfs: convert lzo_decompress() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/9f9a4e43a870
  - [f2fs-dev,12/14] btrfs: convert zstd_decompress() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/b70f3a45464b
  - [f2fs-dev,13/14] btrfs: convert btrfs_decompress() to take a folio
    https://git.kernel.org/jaegeuk/f2fs/c/aeb6d8814841
  - [f2fs-dev,14/14] btrfs: convert copy_inline_to_page() to use folio
    (no matching commit)

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel