On Sat, Aug 8, 2020, 00:01 Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Aug 6, 2020 at 7:24 PM Richard W.M. Jones <rjones@redhat.com> wrote:
On Thu, Aug 06, 2020 at 06:46:06PM +0300, Nir Soffer wrote:
Given the poor results, I suspect that that handles created using same connection share a lock. This also makes sense if connection abstract a blocking socket.
Nice theory, but it didn't work. Again more handles = slower, broadly speaking:
16 coroutines, 16 handles:
real 1m36.920s user 0m0.112s sys 0m1.641s
8 / 8:
real 1m27.946s user 0m0.110s sys 0m1.652s
4 / 4:
real 1m23.027s user 0m0.100s sys 0m1.600s
2 / 2:
real 1m6.089s user 0m0.102s sys 0m1.658s
1 / 1:
real 1m9.540s user 0m0.083s sys 0m1.669s
The patch I'm using now is attached.
There are 2 issues:
1. We create the connection and handle with uninitialized memory, and later with memory used by the previous connection/handle. This may not matter if the library initializes all fields of the struct, but it is safer to zero the memory.
2. We create the handlers in request threads, so most likely not in the same thread. This may be ok, but risky.
I moved the creation of all connections and handles to populate_pool(), called from vddk_open(). This may create more connections and handles than needed if the client does not use multiple inflight requests, but this is not important now.
The code compiles but I cannot test it. Does it make any difference?
Richard, did you test this?
Nir
Rich.
-- Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/