Re: Trying to understand OOM killer

[Michal Hocko]

On Sun 12-02-17 14:47:13, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> since some time, at Linux 4.8, 4.9, and 4.10-rc6, the OOM kicks in on a
> 8 GB machine.
> 
> ```
> Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat invoked oom-killer: gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=

The output is truncated. Could you send the full oom report? But this
smells like an example of the lowmem exhaustion. This is a lowmem
request on 32b system
[...]
> Feb 12 08:21:53 asrocke350m1 kernel: Node 0 active_anon:479572kB inactive_anon:70712kB active_file:125844kB inactive_file:876364kB unevictable
> Feb 12 08:21:53 asrocke350m1 kernel: DMA free:3840kB min:788kB low:984kB high:1180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactiv
> Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 763 7663 7663
> Feb 12 08:21:53 asrocke350m1 kernel: Normal free:38764kB min:38828kB low:48532kB high:58236kB active_anon:0kB inactive_anon:0kB active_file:16
> Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 0 55201 55201

lowmem is on the min watermark while there is no anonymous memory to be
reclaimed and we cannot really tell how much of the page cache as it is
truncated. We also do not know how large is the request because the
order part is missing. __GFP_COMP would suggest higher order request.

In short it is very likely that the OOM killer is genuine because the
given allocation request cannot be satisfied because the low mem
(~896MB) is depleted. This is an inherent problem of 32b kernels
unfortunately. Maybe there is a larger memory consumer in newer
kernels which changed the picture for you.
-- 
Michal Hocko
SUSE Labs