Sometimes you do not need a new driver or a rewritten subsystem to speed up the kernel. Sometimes it is enough to move a couple of lines that were doing pointless work for years. That is exactly what Fengnan Chang from ByteDance did: he moved a memset() call in the iomap layer and squeezed out about 5% more IOPS on ext4 and XFS. The change lands in Linux 7.2.

What iomap Is

iomap is the kernel’s shared I/O mapping layer. Filesystems like ext4, XFS and exFAT use it to translate a file offset into a concrete location on the block device. The heart of the layer is the iomap_iter() loop: for a given file range it asks the filesystem to fill in a struct iomap describing the next contiguous chunk, performs the I/O, then asks for the next chunk until the range is done.

What Actually Changed

At the start of every iteration the code cleared the iomap and srcmap structures with memset(..., 0, sizeof(...)). It did so unconditionally, including after the final iteration, when there is nothing left to map and the caller discards the iterator anyway.

Previously a single helper did two things at once: it cleaned up the folio batch and zeroed the structures:

static inline void iomap_iter_reset_iomap(struct iomap_iter *iter)
{
        if (iter->iomap.flags & IOMAP_F_FOLIO_BATCH) {
                folio_batch_release(iter->fbatch);
                folio_batch_reinit(iter->fbatch);
                iter->iomap.flags &= ~IOMAP_F_FOLIO_BATCH;
        }
        iter->status = 0;
        memset(&iter->iomap, 0, sizeof(iter->iomap));
        memset(&iter->srcmap, 0, sizeof(iter->srcmap));
}

After the change the folio batch cleanup was split out from the zeroing, and both memset() calls were moved so they only run when iteration continues. When iomap_iter() finishes and returns a value <= 0, the zeroing simply does not happen, because nobody needs it anymore.

Why Two Lines Give You 5%

On a modern NVMe drive a single 4k operation is microscopic, and the bottleneck becomes the CPU and memory write bandwidth, not the disk itself. Under a workload of hundreds of thousands or millions of operations per second, every pointless memset of two structures, run on every operation, adds up to a measurable overhead. Removing that waste from the hot path is exactly where those few percent come from.

It shows best in a synthetic but realistic scenario: 4k random reads via io_uring in polling mode on a fast NVMe. This is a workload where every cycle counts, and a difference of about 5% IOPS is clearly measurable and reproducible on both ext4 and XFS.

Who and Where

The patch was written by Fengnan Chang at ByteDance and pulled into the VFS/iomap tree by Christian Brauner. Commit bd6a1379a41a lives in fs/iomap/iter.c and ships with Linux 7.2, expected roughly in August 2026. The press counted the change differently, as two or three lines, depending on how you treat the moved rows. The point is the same: this is a relocation of existing code, not a new algorithm.

Takeaway

This is a good reminder that mature code still hides such treats. A defensive memset on every iteration looked harmless and bothered nobody for years, until someone profiled the hot path under extreme IOPS. If you are optimizing your own code, start with a profiler and a simple question: does the thing you do in a loop really need to run every single time?

Sources: Phoronix, commit on git.kernel.org, thread on lore.kernel.org, XDA, Linux Magazine