On Wed, Mar 21, 2007 at 01:55:35PM +0000, Mark McLoughlin wrote:
- I think the use case is a little different - generally in
libvirt,
we're only allocating very small chunks where the CPU hit for
initialisation would be negligible and would never show up on a
profile. I'd prefer to take the minor hit of zero-initialising
most/all memory for programming ease.
- If our wrappers always zero-initialise, we don't need the
"initialise to -1 when debugging" thing.
- If we rely on calloc() zero-initialising in our wrappers, we give
opportunity for libc to optimise where it knows the memory is
already initialised - e.g. where it's mmap()ing the memory
from /dev/zero
okay, okay, let's use calloc() for libvirt, but then there is a number of
places where I probably used memset() for zeroing, they should all be cleaned
up.
Ah, memory usage reports ... nice. Would such a report be less
useful
with the two mixed together, though? e.g. I personally would just like
to see the libvirt memory usage, rather than libxml2, in such a report.
well memory allocated by libxml2 as strings my be kept for libvirt own usage
Again, though, I think libvirt has slightly different needs from a
malloc() wrapper.
yes, agreed.
> okay, I assume those reporting layers are missing ATM, right
?
Nope, it's all there.
See, in qemudAddIptablesRules() we set VIR_ERR_NO_MEMORY if
iptablesContextNew() returns NULL, qemudAutostartConfigs() calls
qemudLog() if an error is set and qemudLog(), in turn, reports to
syslog.
then all calloc/malloc calls in qemud should get that report code
(maybe factored to avoid repeated code ?)
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/