[libvirt] [RFC] Introduce API for retrieving bulk domain stats
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains. The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will: 1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag) 2) Stats for multiple (all) domains can be queried at once and are returned in one call. This will allow to decrease the overhead necessary to issue multiple calls per domain multiplied by the count of domains. 3) Selectable (bit mask) fields in the returned format. This will allow to retrieve only specific stats according to the APPs need. The returned XML will have the following format: <domainstats> <domain name='vm1'> <state>running</state> <cpus> <cpu id='1'> <state>running</state> <time>10001231231</time> </cpu> <cpu id='2'> <state>offline</state> <time>10001231231</time> <cpu> </cpus> ... </domain> <domain name='vm2'> <state>paused</state> ... </domain> <domain name='vm3'> <state>running</state> ... </domain> </domainstats> Initially the implementation will introduce the option to retrieve block, interface and cpu stats with the possibility to add more in the future. The stats groups will be enabled using a bit field @stats passed as the function argument. A few groups for inspiration: VIR_DOMAIN_STATS_CPU VIR_DOMAIN_STATS_BLOCK VIR_DOMAIN_STATS_INTERFACE As this is a first draft and dump of my mind on this subject it may be a bit rough, so suggestions are welcome. Thanks for looking. Peter --- include/libvirt/libvirt.h.in | 12 ++++ src/driver.h | 8 +++ src/libvirt.c | 127 +++++++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 7 +++ 4 files changed, 154 insertions(+) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 47ea695..72ab617 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -2501,6 +2501,18 @@ int virDomainDetachDeviceFlags(virDomainPtr domain, int virDomainUpdateDeviceFlags(virDomainPtr domain, const char *xml, unsigned int flags); +char *virConnectGetAllDomainStats(virConnectPtr conn, + unsigned int stats, + unsigned int flags); + +char *virDomainListGetStats(virDomainPtr *doms, + unsigned int stats, + unsigned int flags); + +char *virDomainGetStats(virDomainPtr dom, + unsigned int stats, + unsigned int flags); + /* * BlockJob API */ diff --git a/src/driver.h b/src/driver.h index 158df79..2650e90 100644 --- a/src/driver.h +++ b/src/driver.h @@ -1191,6 +1191,13 @@ typedef int unsigned int flags); +typedef char * +(*virDrvDomainListGetStats)(virConnectPtr conn, + virDomainPtr *doms, + unsigned int ndoms, + unsigned int stats, + unsigned int flags); + typedef struct _virDriver virDriver; typedef virDriver *virDriverPtr; @@ -1411,6 +1418,7 @@ struct _virDriver { virDrvDomainSetTime domainSetTime; virDrvNodeGetFreePages nodeGetFreePages; virDrvConnectGetDomainCapabilities connectGetDomainCapabilities; + virDrvDomainListGetStats domainListGetStats; }; diff --git a/src/libvirt.c b/src/libvirt.c index 992e4f2..10e0b70 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -21341,3 +21341,130 @@ virConnectGetDomainCapabilities(virConnectPtr conn, virDispatchError(conn); return NULL; } + + +/** + * virConnectGetAllDomainStats: + * @conn: pointer to the hypervisor connection + * @stats: stats to return, binary OR of virDomainStats + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Report statistics of various parameters for a running VM. + * + * Returns an XML containing the requested stats or NULL on error. The + * returned string shall be freed by the caller. + */ +char * +virConnectGetAllDomainStats(virConnectPtr conn, + unsigned int stats, + unsigned int flags) +{ + char *ret = NULL; + + VIR_DEBUG("conn=%p, stats=0x%x, flags=0x%x", + conn, stats, flags); + + virResetLastError(); + + virCheckConnectReturn(conn, NULL); + + if (!conn->driver->domainListGetStats) { + virReportUnsupportedError(); + goto cleanup; + } + + ret = conn->driver->domainListGetStats(conn, NULL, 0, stats, flags); + + cleanup: + if (!ret) + virDispatchError(conn); + + return ret; +} + + +/** + * virDomainListGetStats: + * @doms: NULL terminated array of domains + * @stats: stats to return, binary OR of virDomainStats + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Report statistics of various parameters for a running VM. + * + * Returns an XML containing the requested stats or NULL on error. The + * returned string shall be freed by the caller. + */ +char * +virDomainListGetStats(virDomainPtr *doms, + unsigned int stats, + unsigned int flags) +{ + virConnectPtr conn = NULL; + virDomainPtr *nextdom = doms; + unsigned int ndoms = 0; + char *ret = NULL; + + VIR_DEBUG("doms=%p, stats=0x%x, flags=0x%x", + doms, stats, flags); + + virResetLastError(); + + if (!*doms) { + virReportError(VIR_ERR_INVALID_ARG, + _("doms array in %s must contain at leas one domain"), + __FUNCTION__); + goto cleanup; + } + + conn = doms[0]->conn; + + if (!conn->driver->domainListGetStats) { + virReportUnsupportedError(); + goto cleanup; + } + + while (*(++nextdom)) { + virDomainPtr dom = *nextdom; + + virCheckDomainGoto(dom, cleanup); + + if (dom->conn != conn) { + virReportError(VIR_ERR_INVALID_ARG, + _("domains in 'doms' array must belong to a " + "single connection in %s"), __FUNCTION__); + goto cleanup; + } + + ndoms++; + } + + ret = conn->driver->domainListGetStats(conn, doms, ndoms, stats, flags); + + cleanup: + if (!ret) + virDispatchError(conn); + return ret; +} + + +/** + * virDomainGetStats: + * @dom: a domain object + * @stats: stats to return, binary OR of virDomainStats + * @flags: extra flags; not used yet, so callers should always pass 0 + * + * Convenience wrapper to get stats for a single domain. + * See virDomainListGetStats for more info. + * + * Returns an XML containing the requested stats or NULL on error. The + * returned string shall be freed by the caller. + */ +char * +virDomainGetStats(virDomainPtr dom, + unsigned int stats, + unsigned int flags) +{ + virDomainPtr doms[2] = {dom, NULL}; + + return virDomainListGetStats(doms, stats, flags); +} diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms index 9f4016a..5bb25ab 100644 --- a/src/libvirt_public.syms +++ b/src/libvirt_public.syms @@ -670,4 +670,11 @@ LIBVIRT_1.2.7 { virConnectGetDomainCapabilities; } LIBVIRT_1.2.6; +LIBVIRT_1.2.8 { + global: + virDomainListGetStats; + virDomainGetStats; + virConnectGetAllDomainStats; +} LIBVIRT_1.2.7; + # .... define new API here using predicted next version number .... -- 2.0.2
----- Original Message -----
From: "Peter Krempa" <pkrempa@redhat.com> To: libvir-list@redhat.com Cc: "Peter Krempa" <pkrempa@redhat.com> Sent: Tuesday, August 19, 2014 3:14:19 PM Subject: [libvirt] [RFC] Introduce API for retrieving bulk domain stats
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains.
Hi, Speaking for VDSM/oVirt, the proposal looks really nice and serves well our needs. Some specific points
The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will:
1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag)
awesome
2) Stats for multiple (all) domains can be queried at once and are returned in one call. This will allow to decrease the overhead necessary to issue multiple calls per domain multiplied by the count of domains.
We had (and still have) a lot of pain from a specific scenario on which a VM becomes unresponsive, 99% of time because QEMU gets stuck, likely on I/O (please remember that oVirt supports more storage types than just NFS, like ISCSI to say the least, so soft mount is not always the solution...). We then need a timeout or a way to signal that some VMs are not responding. Moreover, if we have N VMs and M not responding (being of course M <= N), would be cool to have a timeout *not* proportional to M... We'd like to avoid to wait M * timeout seconds before to know that some of them are failing :) Most importantly, the call should somehow report *all* the failed VMs. Let me try to summarize. Let's say we have 10 VMs (0-9), of which VMs 3,4,7,9 are failing (N=10, M=4). We'd like to wait less than M=4*timeout seconds and, maybe most importantly, we'll need to know that all of the above have failed, not just the one (maybe the first). The reason is our management app, VDSM, needs to report all the not responding VMs. Maybe an entry into the XML data for a not responding VM would be OK
3) Selectable (bit mask) fields in the returned format. This will allow to retrieve only specific stats according to the APPs need.
awesome as well [...]
Initially the implementation will introduce the option to retrieve block, interface and cpu stats with the possibility to add more in the future.
I filed a list of APIs relevant for VDSM here: https://bugzilla.redhat.com/show_bug.cgi?id=1113116#c1 Turns out that the list could be narrowed down to virDomainBlockInfo <- for highest sector of a block virDomainGetInfo <- for balloon stats virDomainGetCPUStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags (will updated the BZ soon)
As this is a first draft and dump of my mind on this subject it may be a bit rough, so suggestions are welcome.
Thanks for looking.
Thanks for the proposal :) I think is a great step forward Thanks and bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On Tue, Aug 19, 2014 at 03:14:19PM +0200, Peter Krempa wrote:
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains.
The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will:
1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag)
I'm not particularly a fan of using XML for this. As a guiding principal we've used structures when we needed APIs for which efficiency is important, and XML for APIs where efficiency is irrelevant. Even with the ability to bulk list data from many VMs at once, I'd think that efficiency is still a very important property of the API. Consider if we have 1000 virtual machines on a host - the XML document is going to get very large and frankly most XML parsers are terribly slow. Would not surprise me if it too several seconds or more to parse an XML doc that this proposed API would return, which I don't think is really viable. JSON might be slightly better in this respect, but not by as much as we might imagine. So I'd rather think we need to figure out a way to map this into some kind of struct, where reading any single statistic could be done in approx constant time, or at least time that is independant of the number of VMs. Much as I dislike the virTypedParameter struct, it might actually be a reasonable fit here. Perhaps a struct struct virDomainRecord { virDomainPtr dom; size_t nparams; virTypedParameter params; }; and the API returns an array of virDomainRecord elements. For the keys in the parameters we could use dot separated components. eg state=runing cpu.online=8 cpu.0.state=running cpu.0.time=10001231231 cpu.1.state=running cpu.1.time=10001231231 ... cpu.7.state=running cpu.7.time=10001231231 This can be fairly efficiently accessed without any parsing involved. The app would have todo an O(n) scan over the array to record the mapping of UUID -> array indexes. Once that's done any single stat can be accessed in O(1) time. I don't think anything XML or JSON based could even come close to this kind of efficiency of access, not to mention that it avoids the need for apps to write XML parsers which will simplify their life no end.
The returned XML will have the following format:
<domainstats> <domain name='vm1'> <state>running</state> <cpus> <cpu id='1'> <state>running</state> <time>10001231231</time> </cpu> <cpu id='2'> <state>offline</state> <time>10001231231</time> <cpu> </cpus> ... </domain> <domain name='vm2'> <state>paused</state> ... </domain> <domain name='vm3'> <state>running</state> ... </domain> </domainstats>
Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 08/19/14 16:43, Daniel P. Berrange wrote:
On Tue, Aug 19, 2014 at 03:14:19PM +0200, Peter Krempa wrote:
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains.
The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will:
1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag)
I'm not particularly a fan of using XML for this. As a guiding principal we've used structures when we needed APIs for which efficiency is important, and XML for APIs where efficiency is irrelevant. Even with the ability to bulk list data from many VMs at once, I'd think that efficiency is still a very important property of the API. Consider if we have 1000 virtual machines on a host - the XML document is going to get very large and frankly most XML parsers are terribly slow. Would not surprise me if it too several seconds or more to parse an XML doc that this proposed API would return, which I don't think is really viable. JSON might be slightly better in this respect, but not by as much as we might imagine.
So I'd rather think we need to figure out a way to map this into some kind of struct, where reading any single statistic could be done in approx constant time, or at least time that is independant of the number of VMs.
Much as I dislike the virTypedParameter struct, it might actually be a reasonable fit here. Perhaps a struct
struct virDomainRecord { virDomainPtr dom; size_t nparams; virTypedParameter params; };
and the API returns an array of virDomainRecord elements. For the keys in the parameters we could use dot separated components. eg
state=runing cpu.online=8 cpu.0.state=running cpu.0.time=10001231231 cpu.1.state=running cpu.1.time=10001231231 ... cpu.7.state=running cpu.7.time=10001231231
This can be fairly efficiently accessed without any parsing involved.
Well while this does reduce the amount of transferred data (by something more than a half, due to the missing end tags). It still requires fair amount of post-processing (parsing) of the output. Potential users of this API will need to split the elements by dots and re-create the hierarchy as it would be in XML. And this introduces the second dimension of complexity (n^2) as you need to go trhough the string identifiers for each returned typed parameter. For C applications this API will be unusable mostly while python clients at least are able to get arrays back.
The app would have todo an O(n) scan over the array to record the mapping of UUID -> array indexes. Once that's done any single stat can be accessed in O(1) time. I don't think anything XML or JSON based could even come close to this kind of efficiency of access, not to mention that it avoids the need for apps to write XML parsers which will simplify their life no end.
Peter
On Tue, Aug 19, 2014 at 05:20:08PM +0200, Peter Krempa wrote:
On 08/19/14 16:43, Daniel P. Berrange wrote:
On Tue, Aug 19, 2014 at 03:14:19PM +0200, Peter Krempa wrote:
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains.
The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will:
1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag)
I'm not particularly a fan of using XML for this. As a guiding principal we've used structures when we needed APIs for which efficiency is important, and XML for APIs where efficiency is irrelevant. Even with the ability to bulk list data from many VMs at once, I'd think that efficiency is still a very important property of the API. Consider if we have 1000 virtual machines on a host - the XML document is going to get very large and frankly most XML parsers are terribly slow. Would not surprise me if it too several seconds or more to parse an XML doc that this proposed API would return, which I don't think is really viable. JSON might be slightly better in this respect, but not by as much as we might imagine.
So I'd rather think we need to figure out a way to map this into some kind of struct, where reading any single statistic could be done in approx constant time, or at least time that is independant of the number of VMs.
Much as I dislike the virTypedParameter struct, it might actually be a reasonable fit here. Perhaps a struct
struct virDomainRecord { virDomainPtr dom; size_t nparams; virTypedParameter params; };
and the API returns an array of virDomainRecord elements. For the keys in the parameters we could use dot separated components. eg
state=runing cpu.online=8 cpu.0.state=running cpu.0.time=10001231231 cpu.1.state=running cpu.1.time=10001231231 ... cpu.7.state=running cpu.7.time=10001231231
This can be fairly efficiently accessed without any parsing involved.
Well while this does reduce the amount of transferred data (by something more than a half, due to the missing end tags). It still requires fair amount of post-processing (parsing) of the output. Potential users of this API will need to split the elements by dots and re-create the hierarchy as it would be in XML. And this introduces the second dimension of complexity (n^2) as you need to go trhough the string identifiers for each returned typed parameter.
For C applications this API will be unusable mostly while python clients at least are able to get arrays back.
I think you mis-understood how I anticipated it being used. You won't want to split the keys on the dots. Rather you would construct the keys you wish to use. eg if you want to print out the status of each virtual CPU in a VM you might have code that looked roughly like this: for (i = 0 ; i < get_int("cpu.online") ; i++) { char key[1024]; sprintf(key, "cpu.%d.status", i) fprint("CPU %d status %s\n", i, get_string(key)) } IOW I don't think applications would take this and try to reconstruct a hierarchical data structure for the whole thing, rather they would directly extract the bits of data they want, possibly putting them into a data structure of their own app specific design Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 08/19/2014 08:43 AM, Daniel P. Berrange wrote:
On Tue, Aug 19, 2014 at 03:14:19PM +0200, Peter Krempa wrote:
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains.
The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will:
1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag)
I'm not particularly a fan of using XML for this. As a guiding principal we've used structures when we needed APIs for which efficiency is important, and XML for APIs where efficiency is irrelevant. Even with the ability to bulk list data from many VMs at once, I'd think that efficiency is still a very important property of the API. Consider if we have 1000 virtual machines on a host - the XML document is going to get very large and frankly most XML parsers are terribly slow. Would not surprise me if it too several seconds or more to parse an XML doc that this proposed API would return, which I don't think is really viable. JSON might be slightly better in this respect, but not by as much as we might imagine.
I'm also not a fan of XML or JSON for the all-domains-in-one-API call in this respect, because for a monolithic string, you can't return it unless you have the data for ALL domains, and you may be hitting RPC limits far sooner than you wish (it doesn't scale well to machines that can run thousands of VMs). I'm also not a fan of JSON in a public API since none of our existing APIs return JSON (well, libvirt-qemu.so returns JSON for arbitrary monitor commands, but that's an unsupported API and is merely exposing what qemu does) - adding JSON to a public API doubles the parsing support that a client has to use. Using XML for a single domain might be doable, though, but that's one XML document per domain, not one XML document for the overall API. I still think we're going to have to come up with some sort of iterative callback approach, where the callback is visited once per domain, rather than trying to return all results in a single call.
So I'd rather think we need to figure out a way to map this into some kind of struct, where reading any single statistic could be done in approx constant time, or at least time that is independant of the number of VMs.
Much as I dislike the virTypedParameter struct, it might actually be a reasonable fit here. Perhaps a struct
struct virDomainRecord { virDomainPtr dom; size_t nparams; virTypedParameter params; };
and the API returns an array of virDomainRecord elements. For the keys in the parameters we could use dot separated components. eg
state=runing cpu.online=8 cpu.0.state=running cpu.0.time=10001231231 cpu.1.state=running cpu.1.time=10001231231 ... cpu.7.state=running cpu.7.time=10001231231
I'm not sure whether this is a net gain on memory usage. It seems like this approach would require that libvirt malloc's each parameter, and that the user must free them all at the end. At least with an XML document, there's only a single malloc'd chunk of memory, rather than lots of pieces, on the API side. On the other hand, if a user is given an XML document, but ends up parsing it into an in-memory representation, they may end up malloc'ing even more memory for that in-memory representation, so our parameters might be a net win after all, where it is just a tradeoff of libvirt instead of the xml parser doing all the mallocing of small chunks. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Aug 19, 2014 at 10:47:24AM -0600, Eric Blake wrote:
On 08/19/2014 08:43 AM, Daniel P. Berrange wrote:
On Tue, Aug 19, 2014 at 03:14:19PM +0200, Peter Krempa wrote:
I'd like to propose a (hopefully) fairly future-proof API to retrieve various statistics for domains.
The motivation is that management layers that use libvirt usually poll libvirt for statistics using various split up APIs we currently provide. To get all the necessary stuff, the mgmt app need to issue Ndomains * Napis calls and cope with the various returned formats. The APIs I'm wanting to introduce here will:
1) Return data in a format that we can expand in the future and is hierarchical. For starters I'll use XML, with possible expansion to something like JSON if it will be favourable for a consumer (switchable by a flag)
I'm not particularly a fan of using XML for this. As a guiding principal we've used structures when we needed APIs for which efficiency is important, and XML for APIs where efficiency is irrelevant. Even with the ability to bulk list data from many VMs at once, I'd think that efficiency is still a very important property of the API. Consider if we have 1000 virtual machines on a host - the XML document is going to get very large and frankly most XML parsers are terribly slow. Would not surprise me if it too several seconds or more to parse an XML doc that this proposed API would return, which I don't think is really viable. JSON might be slightly better in this respect, but not by as much as we might imagine.
I'm also not a fan of XML or JSON for the all-domains-in-one-API call in this respect, because for a monolithic string, you can't return it unless you have the data for ALL domains, and you may be hitting RPC limits far sooner than you wish (it doesn't scale well to machines that can run thousands of VMs). I'm also not a fan of JSON in a public API since none of our existing APIs return JSON (well, libvirt-qemu.so returns JSON for arbitrary monitor commands, but that's an unsupported API and is merely exposing what qemu does) - adding JSON to a public API doubles the parsing support that a client has to use. Using XML for a single domain might be doable, though, but that's one XML document per domain, not one XML document for the overall API.
I still think we're going to have to come up with some sort of iterative callback approach, where the callback is visited once per domain, rather than trying to return all results in a single call.
So I'd rather think we need to figure out a way to map this into some kind of struct, where reading any single statistic could be done in approx constant time, or at least time that is independant of the number of VMs.
Much as I dislike the virTypedParameter struct, it might actually be a reasonable fit here. Perhaps a struct
struct virDomainRecord { virDomainPtr dom; size_t nparams; virTypedParameter params; };
and the API returns an array of virDomainRecord elements. For the keys in the parameters we could use dot separated components. eg
state=runing cpu.online=8 cpu.0.state=running cpu.0.time=10001231231 cpu.1.state=running cpu.1.time=10001231231 ... cpu.7.state=running cpu.7.time=10001231231
I'm not sure whether this is a net gain on memory usage. It seems like this approach would require that libvirt malloc's each parameter, and that the user must free them all at the end. At least with an XML document, there's only a single malloc'd chunk of memory, rather than lots of pieces, on the API side. On the other hand, if a user is given an XML document, but ends up parsing it into an in-memory representation, they may end up malloc'ing even more memory for that in-memory representation, so our parameters might be a net win after all, where it is just a tradeoff of libvirt instead of the xml parser doing all the mallocing of small chunks.
NB I'm not really thinking about mlloc overhead per se, but rather the CPU overhead inherent in parsing a document format that is as complex as XML is. Even so I'm confident that both building & parsing the XML would have far more mallocs involved than a typed parameter based approach. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (4)
-
Daniel P. Berrange -
Eric Blake -
Francesco Romani -
Peter Krempa