Even running this with lots of extra debugging it seems to be doing
what is expected. I can't see the bug if there is one.
Note I'm only testing qemu-img convert as that is what's relevant to
virt-v2v. Previously I was using a hand-written test using libnbd
that did random reads across the disk, and showed a modest improvement
with 8 handles.
Here are the results across a range of pool sizes, all with -W -m 16:
1 handle:
real 1m8.031s
user 0m0.112s
sys 0m1.560s
2 handles:
real 1m6.465s
user 0m0.106s
sys 0m1.607s
4 handles:
real 1m21.488s
user 0m0.126s
sys 0m1.620s
8 handles:
real 1m27.790s
user 0m0.099s
sys 0m1.625s
16 handles:
real 1m33.974s
user 0m0.124s
sys 0m1.718s
I also tried matching the number of coroutines to the number
of handles in the pool (ie pool-max == -m):
1 coroutine, 1 handle:
real 1m9.545s
user 0m0.083s
sys 0m1.592s
2 coroutines, 2 handles:
real 1m6.130s
user 0m0.078s
sys 0m1.567s
4 coroutines, 4 handles:
real 1m22.109s
user 0m0.107s
sys 0m1.690s
8 coroutines, 8 handles:
real 1m26.490s
user 0m0.108s
sys 0m1.650s
16 coroutines, 16 handles (same as last result above):
real 1m33.974s
user 0m0.124s
sys 0m1.718s
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW