On Sun 01-09-19 22:43:05, Thomas Lindroth wrote:
After upgrading to the 4.19 series I've started getting problems with early OOM.
What is the kenrel you have updated from? Would it be possible to try the current Linus' tree?
I run a Gentoo system and do large compiles like the chromium browser in a v1 memory cgroup. When I build chromium in the memory cgroup the OOM killer runs and kills programs outside of the cgroup. This happens even when there is plenty of free memory both in and outside of the cgroup.
[...]
[ 1146.798696] emerge invoked oom-killer: gfp_mask=0x0(), nodemask=(null), order=0, oom_score_adj=0 [ 1146.798699] emerge cpuset= [ 1146.798701] / [ 1146.798703] mems_allowed=0 [ 1146.798705] CPU: 4 PID: 16719 Comm: emerge Not tainted 4.19.69 #43 [ 1146.798707] Hardware name: Gigabyte Technology Co., Ltd. Z97X-Gaming G1/Z97X-Gaming G1, BIOS F9 07/31/2015 [ 1146.798708] Call Trace: [ 1146.798713] dump_stack+0x46/0x60 [ 1146.798718] dump_header+0x67/0x28d [ 1146.798721] oom_kill_process.cold.31+0xb/0x1f3 [ 1146.798723] out_of_memory+0x129/0x250 [ 1146.798728] pagefault_out_of_memory+0x64/0x77 [ 1146.798732] __do_page_fault+0x3c1/0x3d0 [ 1146.798735] do_page_fault+0x2c/0x123 [ 1146.798738] ? page_fault+0x8/0x30 [ 1146.798740] page_fault+0x1e/0x30
This is not a memcg oom killer and the oom killer itself is a reaction to the allocation not making a forward progress. It smells like something in the page fault path has return ENOMEM leading to VM_FAULT_OOM. Seeing unexpected SLUB allocation failures would suggest that something is not really working properly there.