'Hang' in OpenVZ RHEL6 when using blkio cgroup controller to throttle IOPs

[GoogleCodeExporter]

I'm experiencing strange behavior when running ioping and using the blkio 
cgroup controller to throttle IOPs. ioping is producing the expected output 
according to what I throttle IOPs at, but it 'hangs' before returning the 
results. I do not see this behavior when not using blkio to throttle IOPs -- 
results are returned much more quickly, as expected.

I am running OpenVZ containers with the latest RHEL6 OpenVZ kernel.

For example, if I run `./ioping -RL .` with IOPs throttled to 150/sec, there is 
a 'pause' for 110 seconds (the length of the pause is pretty consistent), and 
then the results get outputted:

--- . (simfs /vz/private/101) ioping statistics ---
451 requests completed in 3008.0 ms, 153 iops, 38.2 mb/s
min/avg/max/mdev = 1.3/6.5/72.5/15.8 ms

Any thoughts as to why this is happening? I'm trying to determine if this has 
to do with the way ioping is coded, or if it's some sort of anomaly with the 
blkio controller itself.

Original issue reported on code.google.com by toddmuel...@gmail.com on 22 Oct 2011 at 12:16

[GoogleCodeExporter]

I not see any delays, at least on 2.6.32-042stab039.5
Plese run it under strace, it will show timings:
strace -rT -o ioping.log ioping -RL .

Original comment by koct9i on 27 Oct 2011 at 2:05

[GoogleCodeExporter]

Please see the attached log file.

Original comment by toddmuel...@gmail.com on 27 Oct 2011 at 5:39

Attachments:

• ioping.log

[GoogleCodeExporter]

0.000591 fsync(3)                  = 0 <234.016687>
it is initial fsync, if there some background writes it will write those files 
too.
you can eliminate this delay if you set throttle only for read requests.

Original comment by koct9i on 28 Oct 2011 at 11:39

[GoogleCodeExporter]

Original comment by koct9i on 2 Nov 2011 at 8:26

• Changed state: WontFix

[GoogleCodeExporter]

Original comment by koct9i on 28 Feb 2013 at 7:53