Re: [Xen-devel] [RFC] Generating Go bindings for libxl

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Tue, Jul 30, 2019 at 9:49 AM George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>
> On 7/30/19 2:48 PM, Tamas K Lengyel wrote:
> > On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
> > <rosbrookn@xxxxxxxxxxxx> wrote:
> >>
> >> Hello,
> >>
> >> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> >> summit earlier this month, "Client Virtualization Toolstack in Go", I 
> >> would like to open
> >> a discussion around the development of Go bindings for libxl. George 
> >> Dunlap,
> >> Nicolas Belouin and I have had some discussion off-line already.
> >>
> >> So far, these are the topics of discussion:
> >
> > Hi Nicholas,
> > to add to the list of topics I just want to mention that perhaps it
> > may be beneficial to consider parts of the go bindings not go to libxl
> > at all. I have been digging through libxl for the past couple months
> > and it's asynchronous callback system is damn near impossible to
> > follow and I just can't shake the feeling that it would be a lot
> > easier to follow if it was in go.
>
> So I don't think we're ever going to switch to golang being our primary
> toolstack language, because calling it from other languages isn't really
> an option.  That means that implementing things like domain creation in
> Go mean duplicating functionality in two places, which is
> extraordinarily expensive from a software-engineering perspective.
>
> FWIW I think the asynchronous callback system just needs better
> documentation.  It always takes me a little bit to get my bearings again
> once I have to change that code, but once I do, everything is
> consistent.  And as I understand it, the external interface was written
> primarily with libvirt in mind, so it would probably be difficult to
> change it while remaining compatible.
>
> > Not to mention the performance
> > issues with the built-in garbage collector
>
> What performance issues were you seeing with libxl's garbage collector?
> I thought it just kept a list of pointers and freed them at the very end.

I didn't investigate too closely but on some occasions a considerable
amount of the execution time was being spent in there according to
callgrind. After everything was finished in a domain creation xl would
just "hang" in there for a while before actually exiting. It was not
very consistent and recompiling libxl sometimes sped things up.
Haven't run into it since I've upgraded to debian buster and a newer
gcc.

>
> > and fork/exec parts.
>
> Since we only fork/exec when we need to do so, this part would probably
> be the same no matter what language it was done in.
>
> That said, very little of this has had much performance analysis -- if
> this is important to you, I'm sure there's lots of low-hanging fruit in
> terms of improvements we could make.
>

Right, it was my distinct impression that for the majority of libxl
tasks speed wasn't really a concern - after all, a second or two extra
for creating a domain would not be of concern for normal use-cases.
For the use-case I'm after, it is
(https://xenproject.atlassian.net/projects/XEN/board?issue-key=XEN-89).

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel