On Tue, Feb 14, 2012 at 12:42:58PM +0000, Paul Brook wrote: > > > abort can create core dumps or start a debugger which is > > > useful for me and maybe other developers, too. > > > > I consider abort() on OOM somewhat eccentric. abort() is for > > programming errors. Resource shortage is an environmental error that is > > sometimes (but not always) caused by a programming error. > > > > I'd rather inconvenience programmers (by making it a little bit harder > > to debug programming errors that cause OOM) than confuse users with > > inappropriate scary "crashes". > > While I agree that abort() is not the most friendly failure method, I don't > tthink it's worth trying to handle OOM gracefully. Once we hit OOM I'd say > we're pretty much beyond hope. The best thing we can do is exist as quickly > as possible. For the vast majority of systems there isn't any reason to > believe things will somehow get better if we try again later. > > Initial guest RAM allocation is maybe a special case worth a polite error. > OTOH if you're near the limit then there's a fair chance the -m allocation > will succeed, but some later allocation will not. > > The only way to handle this rebustly is to pre-allocate all the memory we're > ever going to need[1]. I don't see that happening.
FWIW, users can already opt-in to pre-allocation if running KVM enabled QEMU -mem-path /dev/shm -mem-prealloc (or /dev/hugepages more usefully) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
