On Fri, Dec 05, 2014 at 04:55:44PM +1100, Christian Marie wrote: > On Fri, Dec 05, 2014 at 10:07:33AM +0900, Joonsoo Kim wrote: > > It looks that there is no stop condition in isolate_freepages(). In > > this period, your system have not enough freepage and many processes > > try to find freepage for compaction. Because there is no stop > > condition, they iterate almost all memory range every time. At the > > bottom of this mail, I attach one more fix although I don't test it > > yet. It will cause a lot of allocation failure that your network layer > > need. It is order 5 allocation request and with __GFP_NOWARN gfp flag, > > so I assume that there is no problem if allocation request is failed, > > but, I'm not sure. > > > > watermark check on this patch needs cc->classzone_idx, cc->alloc_flags > > that comes from Vlastimil's recent change. If you want to test it with > > 3.18rc5, please remove it. It doesn't much matter. > > > > Anyway, I hope it also helps you. > > Thank you, I will try this next week. If it improves the situation do you think > that we have a good chance of merging it upstream? I should think that > backporting such a fix would be a hard sell. I think that if it improves the situation, it could be merged into upstream. If the patch fix real issue, it is a candidate for stable tree. Thanks. -- 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>