search for: 11m28

...tions: > > Tests (1) and (2) are about the same within noise. > > Test (3) is making 8 times as many requests as test (1), so I think > it's fair to compare the 8 x time taken by test (1) (ie. the time it > would have taking to make 80,000 requests): > > Test (1) * 8 = 11m28 > Test (3) = 7m11 That's pretty good results, 62% faster. What is the request size used? I would test 1, 2, 4, 8 MiB reads. > So if we had a client which could actually use multi-conn then this > would be a reasonable win. It seems like there's still a lot of > lockin...

Nir, BTW what are you using for performance testing? As far as I can tell it's not possible to make qemu-img convert use multi-conn when connecting to the source (which is going to be a problem if we want to use this stuff in virt-v2v). Instead I've hacked up a copy of this program from libnbd: https://github.com/libguestfs/libnbd/blob/master/examples/threaded-reads-and-writes.c so

...ser 0m2.891s sys 0m6.037s My observations: Tests (1) and (2) are about the same within noise. Test (3) is making 8 times as many requests as test (1), so I think it's fair to compare the 8 x time taken by test (1) (ie. the time it would have taking to make 80,000 requests): Test (1) * 8 = 11m28 Test (3) = 7m11 So if we had a client which could actually use multi-conn then this would be a reasonable win. It seems like there's still a lot of locking going on somewhere, perhaps inside VDDK or in the server. It's certainly nowhere near a linear speedup. The patch does at lea...