On Wed 18-07-18 01:45:49, Marc Lehmann wrote: > On Tue, Jul 10, 2018 at 02:32:22PM +0200, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > then we are out of luck. It is quite unfortunate that nvidia really > > insists on having order-3 allocation. Maybe it can use kvmalloc or use > > __GFP_RETRY_MAYFAIL in current kernels. > > Please note that nvidia is really just one of many causes. For example, > right now, on one of our company servers with 25GB of available RAM and > no nvidia driver on linux 4.14.43, I couldn't start any kvm until I did a > manual cache flush: > > ~# vmctl start ... > ioctl(KVM_CREATE_VM) failed: 12 Cannot allocate memory > failed to initialize KVM: Cannot allocate memory > ~# free > total used free shared buff/cache available > Mem: 32619348 6712028 989540 21652 24917780 25430736 > Swap: 33554428 249676 33304752 > ~# sync; echo 3 >/proc/sys/vm/drop_caches > ~# vmctl start ... > [successful] > > reason was an order-6 allocation by kvm: > > 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. If kvm doesn't really require the physically contiguous memory then 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? -- Michal Hocko SUSE Labs
