[Libguestfs] [PATCH nbdkit 2/2] vddk: Relax thread model to PARALLEL and implement a disk handle pool.

[Richard W.M. Jones]

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 at 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