Re: [LTP] [PATCH v2] io: fix really slow dio_sparse on certain systems

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> The reason why dio_sparse is happening to be slow on certain systems is
> that, if data buffering is slow, we run more buffered read() for one
> single dio write(). This slows down the whole test, because for each
> read() we always need to move data from kernel space to user space.

I guess it's not about slow buffering. What I suppose happens is that
every time the writer thread writes with O_DIRECT it invalidates the
page cache and we have to re-read everything from disk. Which measn that
the data are often removed from the cache between the reads and the
reader processes are often forced to re-read the data from the disk. If
there was no O_DIRECT reader thread the first child that happens to read
a file block would cause kernel to put it into the page cache and all
other children would just copy that data without a need to reach the
disk at all.

However the test should finish as fast as the writer finishes writing
the file. So slow readers shouldn't matter unless there is some serious
contention on the disk I/O. That's probably the reason you are aligning
the writer as well.

What is the difference in runtime between test before and after this
patch on the slow hardware?

The only thing I wonder about is that if we aren't dropping some
coverage along with speeding up the test. For the reading part I guess
it doesn't matter that much how big the blocks are (if we speed up the
test we finish faster and do less operations, but that is something we
can live with). If we align the writer it may write directly whole
blocks instead of reading a block, modifying it and writing it back.
Looking at the runtest files, we do have dio_sparse there with a
different write block sizes, so the default shouldn't matter that much,
so why do we bother changing it?

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp