On Sat, Aug 08, 2020 at 12:01:23AM +0300, Nir Soffer wrote:
On Thu, Aug 6, 2020 at 7:24 PM Richard W.M. Jones
<rjones(a)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?
I've had a look at this code now, but unfortunately we cannot do it
this way. Opening a VDDK handle is *slow* - by which I mean it takes
several seconds (3.1 seconds on my two back-to-back machines over
gigabit ethernet). Opening 8 of them for any connection is not going
to fly, or even a smaller pool.
(There were other problems which are easily fixable, such as in_use
always being true, but the above problem is the main one.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top