On 2024/1/24 15:18, Matthew Wilcox wrote:
On Wed, Jan 24, 2024 at 02:33:22PM +1030, Qu Wenruo wrote:
I'm pretty sure we would have some filesystems go utilizing larger folios to
implement their multi-page block size support.
Thus in that case, can we have an interface change to make all folio
versions of filemap_*() to accept a file offset instead of page index?
You're confused. There's no change needed to the filemap API to support
large folios used by large block sizes. Quite possibly more of btrfs
is confused, but it's really very simple. index == pos / PAGE_SIZE.
That's all. Even if you have a 64kB block size device on a 4kB PAGE_SIZE
machine.
Yes, I understand that filemap API is always working on PAGE_SHIFTed index.
The concern is, (hopefully) with more fses going to utilized large
folios, there would be two shifts.
One folio shift (ilog2(blocksize)), one PAGE_SHIFT for filemap interfaces.
And I'm pretty sure it's going to cause confusion, e.g. someone doing
the conversion without much think, and all go the folio shift, even for
filemap_get_folio().
Thus I'm wondering if it's possible to get a bytenr version of
filemap_get_folio().
(Or is it better just creating an inline wrapper inside the fs to avoid
confusion?)
That implies that folios must be at least order-4, but you can still
look up a folio at index 23 and get back the folio which was stored at
index 16 (range 16-31).
Yep, that's also what I expect, and that is very handy.
Thanks,
Qu
hugetlbfs made the mistake of 'hstate->order' and it's still not fixed.
It's a little better than it was (thanks to Sid), but more work is needed.
Just use the same approach as THPs or you're going to end up hurt.
