Re: [RFC PATCH v1 0/3] iomap: convert to in-iter ->iomap_next() model

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/6/25 10:47, Joanne Koong wrote:
> This is submitted to get some feedback on what converting to an in-iter
> ->iomap_next() model would look like. It revives Matthew's previous RFC [1],
> which had the same goal.
> 
> The series merges ->iomap_begin()/->iomap_end() into a single ->iomap_next()
> callback (patches 1-2) and shows an example of devirtualizing the callbacks on
> a hot path so the indirect call through struct iomap_ops is avoided (patch 3).
> This series is on top of vfs.all (commit e7a6d06e3c3e8).
> 
> A few questions:
> * is this roughly the in-iter direction you had in mind?
> * is removing the indirect call still worth it? My understanding is that
>    indirect calls are cheap on modern eIBRS hardware and the conversion adds
>    some per-filesystem boilerplate, so I'm unsure if it carries its weight. If
>    not, do you think the in-iter model is still worth having on its own?


As I mentioned a year ago, I really hope this way can be proceed
to avoid iomap iter-callback models:

https://lore.kernel.org/r/20250905152118.GE1587915@frogsfrogsfrogs

And in that way, iomap can be more flexible as a fs IO library.

Thanks,
Gao Xiang

> 
> Thanks,
> Joanne
> 
> [1] https://lore.kernel.org/linux-fsdevel/20200728173216.7184-1-willy@infradead.org/T/#u