openstack team mailing list archive

[Yun Mao <yunmao@xxxxxxxxx>]

I took a hack and made all C-based libvirt calls using tpool. It
wasn't that bad..

https://github.com/maoy/nova/commit/757bfcb239c62c23c8455a507389efe9c1a2676e

>From my limited testing, it works fine. At least snapshot doesn't
block the compute node anymore.

Yun

On Tue, Mar 13, 2012 at 2:04 PM, Johannes Erdfelt <johannes@xxxxxxxxxxx> wrote:
> On Tue, Mar 13, 2012, Yun Mao <yunmao@xxxxxxxxx> wrote:
>> There are two places in the current master branch that use tpool:
>> NWFilterFirewall and XenAPISession. Are they safe?
>
> I've looked at XenAPISession and it appears to be safe. It doesn't use
> logging nor any other locks.
>
> It does use other Python modules, but they appear to be fine too.
>
> I've never looked at NWFilterFirewall since I've been doing almost all
> of my development on xenapi.
>
>> I think if it's a pure C-based API call, then monkey patch should not
>> mess with it and it shouldn't try to reschedule among co-routines,
>> right?
>
> If it's 100% C, then it's most likely safe. There are ways that it can
> become unsafe, but it really needs to go out of it's way to do so.
>
>> After examining, the code, I see all libvirt-based calls are blocking,
>> and XenAPIs are non-blocking. This probably makes a huge difference in
>> a non-trivial deployment. However, libvirt-based KVM is probably the
>> most widely adopted choice right now, which is very strange..
>
> Yeah, it's not clear to me why only that one call in libvirt is handed
> off to a tpool thread. I'm not all that familiar with libvirt, nor do I
> use it, so I haven't looked into that.
>
> JE
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp