linux-kernel - Re: Still OOM problems with 4.9er kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2016 09:24:29 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Gerhard Wiesinger <lists@...singer.com>
Cc:     Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Still OOM problems with 4.9er kernels

On Sat 10-12-16 14:50:34, Gerhard Wiesinger wrote:
[...]
> IMHO: The OOM killer should NOT kick in even on the highest workloads if
> there is swap available.

This is not so simple. Take a heavy swap trashing situation as an
example. You still have a lot of swap space and an anonymous memory
which can be swapped out but if the workload simply keeps refaulting
the swapped out memory all the time then you can barely make any further
progress and end up in the swap IO hell. Invoking the OOM killer in such
a situation would be a relief to make the system usable again.

> https://www.spinics.net/lists/linux-mm/msg113665.html
> 
> Yeah, but I do think that "oom when you have 156MB free and 7GB
> reclaimable, and haven't even tried swapping" counts as obviously
> wrong.

No question about this part of course.

> So Linus also thinks that trying swapping is a must have. And there
> always was enough swap available in my cases. Then it should swap
> out/swapin all the time (which worked well in kernel 2.4/2.6 times).
> 
> Another topic: Why does the kernel prefer to swap in/swap out instead of use
> cache pages/buffers (see vmstat 1 output below)?

In the vast majority cases it is quite contrary. We heavily bias page
cache reclaim in favor of the anonymous memory. Have a look at
get_scan_count function which determines the balance.

I would need to see /proc/vmstat collected during this time period to
tell you more about why the particular balance was used.

[...]

> With kernel 4.7./4.8 it was really reaproduceable at every dnf update. With
> 4.9rc8 it has been much much better. So something must have changed, too.

that is good to hear but I it would be much better to collect reclaim
related data so that we can analyse what is actually going on here.

> As far as I understood it the order is 2^order kB pagesize. I don't think it
> makes a difference when swap is not used which order the memory allocation
> request is.
> 
> BTW: What were the commit that introduced the regression anf fixed it in
> 4.9?

I cannot really answer this without actually understanding what is going
on here and for that I do not have the relevant data.
-- 
Michal Hocko
SUSE Labs