On Sun, 10 Jan 2021, Matthew Wilcox wrote: > > That is the reason for that 10% degradation with read_iter. > > You seem to be focusing on your argument for "let's just permit > filesystems to implement both ->read and ->read_iter". My suggestion > is that we need to optimise the ->read_iter path, but to do that we need > to know what's expensive. > > nvfs_rw_iter_locked() looks very complicated. I suspect it can > be simplified. I split it to a separate read and write function and it improved performance by 1.3%. Using Al Viro's read_iter improves performance by 3%. > Of course new_sync_read() needs to be improved too, > as do the other functions here, but fully a third of the difference > between read() and read_iter() is the difference between nvfs_read() > and nvfs_rw_iter_locked(). I put counters into vfs_read and vfs_readv. After a fresh boot of the virtual machine, the counters show "13385 4". After a kernel compilation they show "4475220 8". So, the readv path is almost unused. My reasoning was that we should optimize for the "read" path and glue the "readv" path on the top of that. Currently, the kernel is doing the opposite - optimizing for "readv" and glueing "read" on the top of it. Mikulas
