lkml.org 
[lkml]   [2021]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Expense of read_iter


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

\
 
 \ /
  Last update: 2021-01-10 22:23    [W:0.115 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site