Re: [RFC] cfq: adapt slice to number of processes doing I/O

[Jeff Moyer <jmoyer@redhat.com>]

Corrado Zoccolo <czoccolo@gmail.com> writes:

> Hi Jeff,
> can you share the benchmark?

Of course, how miserly of me!

http://people.redhat.com/jmoyer/cfq-regression-tests-0.0.1.tar.gz

> I think I have to fix the min slice to consider priority, too, to
> respect the priorities when there are many processes.
>
> For the fairness at a single priority level, my tests show that
> fairness is improved with the patches (comparing minimum and maximum
> bandwidth for a set of 32 processes):
>
> Original:
> Run status group 0 (all jobs):
>    READ: io=14192KiB, aggrb=480KiB/s, minb=7KiB/s, maxb=20KiB/s,
> mint=30001msec, maxt=30258msec
>
> Run status group 1 (all jobs):
>    READ: io=829292KiB, aggrb=27816KiB/s, minb=723KiB/s,
> maxb=1004KiB/s, mint=30004msec, maxt=30529msec
>
> Adaptive:
> Run status group 0 (all jobs):
>    READ: io=14444KiB, aggrb=488KiB/s, minb=12KiB/s, maxb=17KiB/s,
> mint=30003msec, maxt=30298msec
>
> Run status group 1 (all jobs):
>    READ: io=721324KiB, aggrb=24140KiB/s, minb=689KiB/s, maxb=795KiB/s,
> mint=30003msec, maxt=30598msec
>
> Are you using random think times? This could explain the discrepancy.

No, it's just a sync read benchmark.  It's the be4-x-8.fio job file in
the tarball mentioned above.  Note that the run-time is only 10 seconds,
so maybe that's not enough to get accurate data?  If you try increasing
it, be careful that you don't read in the entire file and wrap back
around, as this is a buffered read test, that will skew the results.

Cheers,
Jeff