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:
pgpdsnv5k2Dd9.pgp
Description: PGP signature