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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>