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. > By judging from this perf report, my second patch would have no impact > to your system. I thought that this excessive cpu usage is started from > the SLUB, but, order 5 kmalloc request is just forwarded to page > allocator in current SLUB implementation, so patch 2 from me would not > work on this problem. I agree with this. > > By the way, is it common that network layer needs order 5 allocation? > IMHO, it'd be better to avoid this highorder request, because the kernel > easily fail to handle this kind of request. Yes, agreed. I'm trying to sort that issue out concurrently. I'm currently collaborating on a patch to get Scatter Gather support for the network layer so that we can avoid these huge allocations. They are large because ipoib in Connected Mode wants a very large MTU (around 65535) and does not do SG in CM.
Attachment:
pgpJ1rsFHGuMn.pgp
Description: PGP signature