Re: Early test: hangs in mm/compact.c w. Linus's 12d7aacab56e9ef185c
From: Vlastimil Babka
Date: Thu Nov 06 2014 - 16:38:14 EST
On 11/06/2014 08:23 PM, P. Christeas wrote:
> On Wednesday 05 November 2014, Vlastimil Babka wrote:
>> Can you please try the following patch?
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1325,13 +1325,6 @@ unsigned long try_to_compact_pages(struct zonelist
>> - compaction_defer_reset(zone, order, false);
>
> NACK :(
Sigh.
> I just got again into a state that some task was spinning out of control, and
> blocking the rest of the desktop.
Well this is similar to reports [1] and [2] except [1] points to
isolate_freepages_block() and your traces only go as deep as compact_zone. Which
probably inlines isolate_migratepages* but I would expect it cannot inline
isolate_freepages* due to invocation via pointer.
> You will see me trying a few things, apparently the first OOM managed to
> unblock something, but a few seconds later the system "stepped" on some other
> blocking task.
>
> See attached log, it may only give you some hint; the problem could well be in
> some other part of the kernel.
Well I doubt that but I'd like to be surprised :)
> In the meanwhile, I'm pulling linus/master ...
Could you perhaps bisect the most suspicious part? It's not a lot of commits
and you seem to be reproducing this quite easily?
commit 447f05bb488bff4282088259b04f47f0f9f76760 should be good
commit 6d7ce55940b6ecd463ca044ad241f0122d913293 should be bad
If that's true, then bisection should find the cause rather quickly.
Oh and did I ask in this thread for /proc/zoneinfo yet? :)
Thanks.
> kcrash.log
>
[1]
http://article.gmane.org/gmane.linux.kernel.mm/124451/match=isolate_freepages_block+very+high+intermittent+overhead
[2] https://lkml.org/lkml/2014/11/4/904
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/