Re: isolate_freepages_block and excessive CPU usage by OSD process

[Christian Marie <christian@ponies.io>]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

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 #2: Type: application/pgp-signature, Size: 819 bytes --]