Re: isolate_freepages_block and excessive CPU usage by OSD process

[Christian Marie <christian@ponies.io>]

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

On Thu, Nov 20, 2014 at 12:10:30AM +0100, Vlastimil Babka wrote:
> As I said, recent kernels received many compaction performance tuning patches,
> and reclaim as well. I would recommend trying them, if it's possible.
> 
> You mention 3.10.0-123.9.3.el7.x86_64 which I have no idea how it relates to
> upstream stable kernel. Upstream version 3.10.44 received several compaction
> fixes that I'd deem critical for compaction to work as intended, and lack of
> them could explain your problems:
> 
> mm: compaction: reset cached scanner pfn's before reading them
> commit d3132e4b83e6bd383c74d716f7281d7c3136089c upstream.
> 
> mm: compaction: detect when scanners meet in isolate_freepages
> commit 7ed695e069c3cbea5e1fd08f84a04536da91f584 upstream.
> 
> mm/compaction: make isolate_freepages start at pageblock boundary
> commit 49e068f0b73dd042c186ffa9b420a9943e90389a upstream.
> 
> You might want to check if those are included in your kernel package, and/or try
> upstream stable 3.10 (if you can't use the latest for some reason).

I built exactly the same kernel with these patches applied, unfortunately it
suffered the same problem. I will now try the latest (3.18-rc5) release
candidate and report back.

Do you have any ideas of where I could be looking to collect data to track down
what is happening here? Here is some perf output again:

http://ponies.io/raw/compaction.png

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]