Re: [RFC PATCH] docs/devel: expand style section of memory management

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Mon, Mar 15, 2021 at 06:04:10PM +0100, Thomas Huth wrote:
>> On 15/03/2021 17.57, Peter Maydell wrote:
>> > On Mon, 15 Mar 2021 at 16:53, Alex Bennée <alex.bennee@linaro.org> wrote:
>> > > -Prefer g_new(T, n) instead of g_malloc(sizeof(T) ``*`` n) for the following
>> > > +Care should be taken to avoid introducing places where the guest could
>> > > +trigger an exit. For example using ``g_malloc`` on start-up is fine
>> > > +if the result of a failure is going to be a fatal exit anyway. There
>> > > +may be some start-up cases where failing is unreasonable (for example
>> > > +speculatively loading debug symbols).
>> > > +
>> > > +However if we are doing an allocation because of something the guest
>> > > +has done we should never trigger an exit. The code may deal with this
>> > > +by trying to allocate less memory and continue or re-designed to allocate
>> > > +buffers on start-up.
>> > 
>> > I think this is overly strong. We want to avoid malloc-or-die for
>> > cases where the guest gets to decide how big the allocation is;
>> > but if we're doing a single small fixed-size allocation that happens
>> > to be triggered by a guest action we should be OK to g_malloc() that
>> > I think.
>> 
>> I agree with Peter. If the host is so much out-of-memory that we even can't
>> allocate some few bytes anymore (let's say less than 4k), the system is
>> pretty much dead anyway and it might be better to terminate the program
>> immediately instead of continuing with the out-of-memory situation.
>
> On a Linux host you're almost certainly not going to see g_malloc
> fail for small allocations at least. Instead at some point the host
> will be under enough memory pressure that the OOM killer activates
> and reaps arbitrary processes based on some criteria it has, freeing
> up memory for malloc to succeed (unless OOM killer picked you as the
> victim).

This happens even for large allocations.  In a prior iteration of the
"When it's okay to treat OOM as fatal?" discussion[1], I showed that
Linux malloc() and g_malloc() happily give me a terabyte of memory I
don't have in 1024 chunks of 1 GiB each.  I just reran the test, same
results.

See also [2].


[1] https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg04229.html
[2] http://turnoff.us/geek/bad-malloc/