Hi Lorenzo and Zi, >>> Is there a reason we can't keep this hack while continuing to push >>> filesystems >>> toward proper large folio support? >> >> IMO - It's time for us to stop allowing filesystems to fail to implement what >> mm requires of them, while still providing a hack to improve performance. >> >> Really this hack shouldn't have been there in the first place, but it was a >> 'putting on notice' that filesystems need to support large folios, which >> has been made amply clear to them for some time. >> >> So yes there will be regressions for filesystems which _still_ do not >> implement this, I'd suggest you focus on trying to convince them to do so >> (or send patches :) >> > > Thank Lorenzo for clarifying the intention of this patchset. > > Hi Rui, > > READ_ONLY_THP_FOR_FS is an experimental feature since 2019 and that means the > feature can go away at any time. > > In addition, Matthew has made a heads-up on its removal [1] several months > ago. > We have not heard any objection since. > > It seems that you care about btrfs with large folio support. Have you > talked to btrfs people on the timeline of moving the large folio support out > of the experimental state? > > > [1] https://lore.kernel.org/all/[email protected]/
Thanks for the clarification. I fully agree with the long-term direction here. Ideally this should be handled by filesystems, and mm has already done a lot of work to make that possible. However, in practice it does not look like simply enabling an experimental feature is sufficient today. I did a quick check of mapping_max_folio_size() across a few common filesystems, and only XFS consistently reaches PMD order under both 4K and 16K base pages. Even ext4 falls short under 16K. PAGE_SIZE = 4K, PMD_SIZE = 2M Filesystem mapping_max_folio_size PMD order ------------------------------------------------------------------ ext4 2M yes btrfs (without experimental) 4K no btrfs (with experimental) 256K no xfs 2M yes PAGE_SIZE = 16K, PMD_SIZE = 32M Filesystem mapping_max_folio_size PMD order ------------------------------------------------------------------ ext4 8M no btrfs (without experimental) 16K no btrfs (with experimental) 256K no xfs 32M yes Given the diversity of filesystems in use, each one requires dedicated engineering effort to implement and validate large folio support, and that assumes both sufficient resources and prioritization on the filesystem side. Even after support lands, coverage across different base page sizes and configurations may take additional time to mature. What I am really concerned about is the transition period: if filesystem support is not yet broadly ready, while we have already removed the fallback path, we may end up in a situation where PMD-sized mappings become effectively unavailable on many systems for some time. This is not about the long-term direction, but about the timing and practical readiness. Thanks, Rui
