With the unexplained but apparently somewhat systematic regression
patterns on certain tests and settings, I wonder if they might be due
to read_stream.c trying to form larger reads, making it a bit lazier.
It tries to see what the next block will be before issuing the
fadvise. I think that means that with small I/O concurrency settings,
there might be contrived access patterns where it loses, and needs
effective_io_concurrency to be set one notch higher to keep up, or
something like that. One way to test that idea would be to run the
tests with io_combine_limit = 1 (meaning 1 block). It issues advise
eagerly when io_combine_limit is reached, so I suppose it should be
exactly as eager as master. The only difference then should be that
it automatically suppresses sequential fadvise calls.
