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. -- Michal Hocko SUSE Labs
