Re: OOM killer changes

[Vlastimil Babka <vbabka@suse.cz>]

On 08/17/2016 02:26 AM, Ralf-Peter Rohbeck wrote:
> No it wasn't yet in the last run. That OOM happened while I compiled the 
> last change.

You mean those pr_infos?

>From those we've got:

Aug 16 17:14:26 fs kernel: [ 1817.044778] XXX: compaction_failed
Aug 16 17:15:37 fs kernel: [ 1888.387817] XXX: compaction_failed
Aug 16 17:17:32 fs kernel: [ 2002.879726] XXX: compaction_failed

e.g. none of the "XXX: no zone suitable for compaction" lines

I think my series in mmotm tree could help here.

> I ran another test with the trace_printk: See attached. Again I ran only 
> a kernel compilation.

so, the trace_printk didn't hit that many times:

grep try_to_release trace_pipe.log | wc -l
52

and vmstat_after shows:

pgmigrate_success 851
pgmigrate_fail 817
compact_migrate_scanned 567689
compact_free_scanned 50744242
compact_isolated 19196
compact_stall 876
compact_fail 801
compact_success 75

pagetype_after:

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate 
Node 0, zone      DMA            1            7            0            0            0 
Node 0, zone    DMA32          883           91           42            0            0 
Node 0, zone   Normal         2750          207          115            0            0 

So while btrfs migrate failures could be real, in this run it was rather the free
scanner struggling due to unmovable blocks, as Joonsoo suggested.

> Ralf-Peter
> 
> On 16.08.2016 00:32, Michal Hocko wrote:
>> On Mon 15-08-16 11:42:11, Ralf-Peter Rohbeck wrote:
>>> This time the OOM killer hit much quicker. No btrfs balance, just compiling
>>> the kernel with the new change did it.
>>> Much smaller logs so I'm attaching them.
>> Just to clarify. You have added the trace_printk for
>> try_to_release_page, right? (after fixing it of course). If yes there is
>> no single mention of that path failing which would support Joonsoo's
>> theory... Could you try with his patch?
> 
> 
> ----------------------------------------------------------------------
> The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>