在 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
