On Mon 23-07-18 01:34:37, Marc Lehmann wrote: > On Wed, Jul 18, 2018 at 10:38:08AM +0200, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > http://data.plan9.de/kvm_oom.txt > > > > That is something to bring up with kvm guys. Order-6 pages are > > considered costly and success of the allocation is by no means > > guaranteed. Unike for orders smaller than 4 they do not trigger the oom > > killer though. > > So 4 is the magic barrier, good to know. Yeah, scientifically proven. Or something along those lines. > In any case, as I said, it's just > an example of various allocations that fail unexpectedly after 4.4, and it's > by no means just nvidia. Large allocation failures shouldn't be directly related to the OOM changes at the time. There were many compaction fixes/enhancements introduced at the time and later which should help those though. Having more examples should help us to work with specific subsystems on a more appropriate fix. Depending on large order allocations has always been suboptimal if not outright wrong. > > > vmalloc fallback would be a good alternative. Unfortunatelly I am not > > able to find which allocation is that. What does faddr2line kvm_dev_ioctl_create_vm+0x40 > > say? > > I suspect I can't run this for an installed kernel without sources/object > files? In this case a precompiled kernel from ubuntu mainline-ppa. > Running faddr2line kvm.ko ... just gives me: > > kvm_dev_ioctl_create_vm+0x40/0x5d1: > kvm_dev_ioctl_create_vm at ??:? You need a vmlinux with debuginfo compiled IIRC. -- Michal Hocko SUSE Labs
