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 <tomas@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
