On Sun, Mar 17, 2024 at 08:09:53AM +0100, Andreas Hindborg wrote: > I was under the impression that using folios also give the advantage > that handles are always head pages. No need to worry about head/tail > pages. If the driver moves to use higher order pages for larger block > sizes, would it then make sense with folios, or are page still > preferred? This is a good question. If you do enhance this driver to support larger block sizes, I would recommend indexing the xarray by sector number instead of page number. You would allocate a compound page, but at no point would you need to ask the page what order it is (you already know), you don't need to change the page flags, etc, etc. The page cache is in a bit of a different spot. It has to support multiple folio sizes for the same file; it has to support folios being split, it has to support lookup from users who don't know what the folio size is, etc, etc. I don't think there's ever a point at which you'd need to call compound_head() because you'd always look up the head page. You'd still want an iterator of some kind to copy to a compound page (because you can only map one at a time). And that might look a lot like the folio copying code. Probably the right way to handle this is for the folio copying code to call the page copying code since a folio is always composed of pages.
