Re: [RFC PATCH] iomap: add fast read path for small direct I/O

[Christoph Hellwig <hch@infradead.org>]

On Thu, Apr 16, 2026 at 11:16:23AM +0800, changfengnan wrote:
> > But it already is a major improvement, and one that would apply outside
> > of narrow special cases.  So I'd really like to see that patch.
> You can see this in:
> https://lore.kernel.org/linux-fsdevel/20260416030642.26744-1-changfengnan@bytedance.com/T/#u

Thanks!

> > All direct I/O requires this.
> > 
> > > - No bounce buffering, fscrypt, or fsverity involved.
> > > - No custom `iomap_dio_ops` (dops) registered by the filesystem.
> > 
> > I'm really curious at what difference this makes.  It removes a few
> > branches, but should not have much of an effect while limiting the
> > applicability a lot.
> Yes, the impact shouldn’t be significant. 
> Since this is just a RFC version to confirm that I’m on the right path, there
> are many aspects that haven’t been fully thought through yet. I haven’t
> tested these scenarios yet, but I’ll add support for them later to
> check  exactly what the impact is.

Sure.  It might also make sense to skip some of this if it brings a big
enough benefit.

> > > +struct iomap_dio_fast_read {
> > > +        struct kiocb        *iocb;
> > > +        size_t                size;
> > > +        bool                should_dirty;
> > > +        struct work_struct        work;
> > > +        struct bio        bio ____cacheline_aligned_in_smp;
> > 
> > Does the cache line alignment matter here?  If yes, can you explain why
> > in a comment?
> 
> I copy this from struct blkdev_dio , I'll do some test to verfiy. 

Thanks.  Btw, another thing that might be worth is to drop the
work_struct and reuse iomap_fail_reads or something similar to it.
This would be a pretty big size reduction.  Additionally we should
be able to kill should_dirty and just rely on bio or kiocb flags.