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

[Michal Hocko <mhocko@kernel.org>]

On Mon 23-07-18 01:34:37, Marc Lehmann wrote:
> On Wed, Jul 18, 2018 at 10:38:08AM +0200, Michal Hocko <mhocko@kernel.org> 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