Re: [libvirt] (Dropping) OOM Handling in libvirt
On 5/13/19 8:28 AM, Michal Privoznik wrote:
On 5/13/19 12:17 PM, Daniel P. Berrangé wrote:
> This is a long mail about ENOMEM (OOM) handling in libvirt. The executive
> summary is that it is not worth the maint cost because:
>
> The long answer follows...
I'm up for dropping OOM handling. Since we're linking with a lot of
libraries I don't think we can be confident that we won't abort() even
now anyway.
I can live with the decision to drop OOM handling, as long as we still
try to gracefully handle any user-requested large allocation (such as
g_try_malloc) and only default to abort-on-failure for the more common
case of small allocations (such as g_malloc).
> 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. Secondly, glib adds some padding around its objects => libvirt's
memory footprint will grow. Thirdly, it's yet another library to link
with (on my system libvirt links with 53 libraries already).
I'm not sold on the fact that glib will ease things, but I do agree that
one reason we have avoided it so far is because of its abort-on-ENOMEM
behavior, and we are now in agreement that this is no longer a blocker
for using glib.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)