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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
