2016-08-17 16:56 GMT+09:00 Vlastimil Babka <vbabka@xxxxxxx>:
> On 08/17/2016 06:48 AM, Ralf-Peter Rohbeck wrote:
>>> ------------>8-----------
>>> diff --git a/mm/compaction.c b/mm/compaction.c
>>> index 9affb29..965eddd 100644
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -1082,10 +1082,6 @@ static void isolate_freepages(struct compact_control *cc)
>>> if (!page)
>>> continue;
>>>
>>> - /* Check the block is suitable for migration */
>>> - if (!suitable_migration_target(page))
>>> - continue;
>>> -
>>> /* If isolation recently failed, do not retry */
>>> if (!isolation_suitable(cc, page))
>>> continue;
>>>
>> That seemed to help a little (subjectively) but still OOM killed a
>> kernel build. The logs are attached.
>
>> grep XXX messages
> Aug 16 20:29:13 fs kernel: [ 6850.467250] XXX: compaction_failed
>
> pagetypeinfo_after:
> Number of blocks type Unmovable Movable Reclaimable HighAtomic Isolate
> Node 0, zone DMA 1 7 0 0 0
> Node 0, zone DMA32 879 93 44 0 0
> Node 0, zone Normal 2862 136 74 0 0
>
> vmstat_after:
> pgmigrate_success 5123
> pgmigrate_fail 4106
> compact_migrate_scanned 62019
> compact_free_scanned 44314328
> compact_isolated 18572
> compact_stall 327
> compact_fail 236
> compact_success 91
> compact_daemon_wake 1162
>
>> grep try_to_release trace_pipe.log | wc -l
> 0
>
> Again, migration failures are there but not so many, and failures to
> isolate freepages stand out. I assume it's because the kernel build
> workload and not the btrfs balance one.
>
> I think the patches in mmotm could make compaction try harder and use
> more appropriate watermarks, but it's not guaranteed that will help.
> The free scanner seems to become more and more a fundamental problem.
Following trace is last compaction trial before triggering OOM.
Free scanner start at 0x27fe00 but actual scan happens at 0x186a00.
And, although log is snipped, compaction fails because it doesn't find
any freepage.
It skips half of pageblocks in that zone. It would be due to
migratetype or skipbit.
Both Vlastimil's recent patches and my work-around should be applied to solve
this problem.
Other part of trace looks like that my work-around isn't applied.
Could you confirm
that?
Thanks.
sh-14869 [000] .... 6850.456639:
mm_compaction_try_to_compact_pages: order=2 gfp_mask=0x27000c0 mode=1
sh-14869 [000] .... 6850.456640:
mm_compaction_suitable: node=0 zone=Normal order=2 ret=continue
sh-14869 [000] .... 6850.456641: mm_compaction_begin:
zone_start=0x100000 migrate_pfn=0x100000 free_pfn=0x27fe00
zone_end=0x280000, mode=sync
sh-14869 [000] .... 6850.456641:
mm_compaction_finished: node=0 zone=Normal order=2 ret=continue
sh-14869 [000] .... 6850.456648:
mm_compaction_isolate_migratepages: range=(0x100000 ~ 0x10002d)
nr_scanned=45 nr_taken=32
sh-14869 [000] .... 6850.456834:
mm_compaction_isolate_freepages: range=(0x186a00 ~ 0x186c00)
nr_scanned=512 nr_taken=0
sh-14869 [000] .... 6850.456842:
mm_compaction_isolate_freepages: range=(0x186800 ~ 0x186a00)
nr_scanned=512 nr_taken=0
> And I really wonder how did all those unmovable pageblocks happen.
> AFAICS zoneinfo shows that most of memory is occupied by file lru pages.
> These should be movable.
>
> --
> 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>
--
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>