Re: [libvirt] (Dropping) OOM Handling in libvirt
On Mon, May 13, 2019 at 03:28:24PM +0200, Michal Privoznik wrote:
On 5/13/19 12:17 PM, Daniel P. Berrangé wrote:
>The tests show we generally do remarkly well at OOM handling, but none the
>less we have *always* found bugs in our handling where we fail to report the
>OOM (as in, continue to run but with missing data), or we crash when cleaning
>up from OOM. Our unit tests don't cover anywhere near all of our codebase
>though. We have great coverage of XML parsing/formatting, and sporadic coverage
>of everything else.
>
>IOW, despite our clever API designs & coding patterns designed to improve our
>OOM handling, we can not have confidence that we will actually operate correctly
>in an OOM scenario.
I beg to disagree. The fact that our cleanup paths are in 99% the same
as error paths means that if there are no mem-leaks (and if
transformation to VIR_AUTOFREE is done the chances are low), then we
propably do good on OOM too.
There possibly might be cases where we dereference the pointer unconditionally
in the cleanup section, regardless of whether the allocation succeeded.
<snip/>
>The implementation
>==================
>
>Assuming a decision to abort on OOM, libvirt can nwo follow QEMU's lead and
>make use of the GLib library.
No, please no. Firstly, glib is a new C dialect that only a few of us
speak.
Well, libvirt C is also a dialect that is even less widely spoken.
Moreover, it will make it easier for QEMU developers to contribute to
libvirt and vica verca.
Also, learning it is much easier than learning a different language
(Rust? Haskell?)
Secondly, glib adds some padding around its objects =>
libvirt's memory footprint will grow.
We also do a lot of unnecessary (re)allocations to simplify the code,
the logic being that the extra developer time spent debugging is not
worth the neligible increase. But this seems like something that's hard
to measure until we rewrite all of libvirt in glib.
Thirdly, it's yet another
library to link with (on my system libvirt links with 53 libraries
already).
Well, if you already have to have glib because of QEMU, why does the
library count matter?
Jano
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)