Re: post linux 4.4 vm oom kill, lockup and thrashing woes

[Michal Hocko <mhocko@kernel.org>]

On Wed 18-07-18 01:45:49, Marc Lehmann wrote:
> On Tue, Jul 10, 2018 at 02:32:22PM +0200, Michal Hocko <mhocko@kernel.org> 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