On Fri, Apr 26, 2024 at 10:12:01PM -0700, Christoph Hellwig wrote: > On Fri, Apr 26, 2024 at 11:43:01AM +0000, Pankaj Raghav (Samsung) wrote: > > Because allocating it during runtime will defeat the purpose. > > Well, what runtime? Either way it seems like we have the infrastructure > now based on the comment from willy. As willy pointed out in that reply, it is allocated on demand, so it might still fail and we might have to revert back to looping. And if we end up using the huge zero page, we should also make sure to decrement to reference in iomap_dio_bio_end_io(), which is not needed when we use ZERO_PAGE. FWIW, I did a prototype with mm_huge_zero_page() in one of the older series. [1] (I forgot to decrement reference in end_io()) but I did not get final response if that is the direction we want to go. Let me know your thoughts. [1]https://lore.kernel.org/linux-xfs/3pqmgrlewo6ctcwakdvbvjqixac5en6irlipe5aiz6vkylfyni@2luhrs36ke5r/#r > > > In anycase, I would like to pursue huge_zero_page folio separately > > from this series. Also iomap_dio_zero() only pads a fs block with > > zeroes, which should never be > 64k for XFS. > > Only if you are limited to 64k block size. >
