On 2/14/25 18:31, Melanie Plageman wrote: > io_combine_limit 1, effective_io_concurrency 16, read ahead kb 16 > > On Fri, Feb 14, 2025 at 12:18 PM Tomas Vondra <to...@vondra.me> wrote: >> >> Based on off-list discussion with Melanie, I ran a modified version of >> the benchmark, with these changes: > > Thanks! It looks like the worst offender is io_combine_limit 1 (128 > kB), effective_io_concurrency 16, read_ahead_kb 16. This is a > combination that people shouldn't run in practice I think -- an > io_combine_limit larger than read ahead. > > But we do still see regressions with io_combine_limit 1, > effective_io_concurrency 16 at other read_ahead_kb values. Therefore > I'd be interested to see that subset (ioc 1, eic 16, diff read ahead > values) with the attached patch. > >> FWIW this does not change anything in the detection of sequential access >> patterns, discussed nearby, because the benchmarks started before Andres >> looked into that. If needed, I can easily rerun these tests, I just need >> a patch to apply. > > Attached a patch that has all the commits squashed + removes > sequential detection. >
OK, it's running. I didn't limit the benchmarks any further, it seems useful to have "full" comparison with the last run. I expect to have the results in ~48 hours, i.e. by Monday. regards -- Tomas Vondra
