On 12/09/15 12:47, Peter Maydell wrote: > On 9 December 2015 at 10:29, Dr. David Alan Gilbert <dgilb...@redhat.com> > wrote: >> (OK, to be honest I think we should protect every allocation - but I do >> have sympathy with the complexity/testing arguments). > > My view on this is that Linux overcommits, so the actual likely > way that "oops, out of memory" will manifest is by some page not > being able to be allocated-on-demand, at which point your process > is toast anyway.
This is a frequent argument, but this behavior is not acceptable for many production workloads (for example, it is not acceptable on my laptop :)), and it can be disabled with the overcommit knobs under /proc/sys/vm. Also, the OOM killer destroying the "wrong" process is a recurrent source of fun. Of course, under memory pressure there is no telling which process will get ENOMEM first, even with overcommit disabled, but that setting at least allows the process to deal with the error, should it choose so. On a heavy duty virtualization host, one can expect that *only* such applications run that can "behave" in response to ENOMEM -- I believe libvirtd is an example? --; hence disabling overcommit is especially valid. (I continue to offer my (unsolicited) opinion in this thread, and I continue encouraging QEMU people to ignore it whenever appropriate. I don't strive to influence the decision; I'd just like to contribute to the well-informed nature of the decision.) Thanks Laszlo > Checking malloc returns is really only checking > your virtual address space allocation, which typically speaking > always succeeds, except in the "we tried to get gigabytes at > once" case... > > thanks > -- PMM >
