Hi everyone, On Fri, Aug 02, 2013 at 02:46:59PM -0500, Alex Thorlton wrote: > This patch implements functionality to allow processes to disable the use of > transparent hugepages through the prctl syscall. > > We've determined that some jobs perform significantly better with thp > disabled, > and we need a way to control thp on a per-process basis, without relying on > madvise.
Are you using automatic NUMA balancing or CPU pinning or was this a short lived computation? If you're not using automatic NUMA balancing or if you're using automatic NUMA balancing and this is a fairly short lived computation, zone_reclaim_mode was broken with THP enabled as it never called into compaction, so with THP enabled you would have a random NUMA placement during page fault to satisfy hugepage allocation (first priority was to get any hugepage from any wrong node, only then it would call compaction). Did you verify the numa placement that you were getting? I fixed the zone_reclaim_mode for THP and posted the fixes on linux-mm, so you may want to try that fix just in case it helps your workload. Chances are you work with a big system where zone_reclaim_mode is enabled by default, and for a test I would suggest you to enable it once even if it's not enabled by default (after applying the fixes) to see if it makes any difference. I just did a push of my latest tree to the master branch of aa.git on kernel.org, so you can just pull that for a quick test with zone_reclaim_mode enabled. NOTE: it's not guaranteed to help but it's worth a try. As you pointed out if the threads are working on separate 4k fragments, it won't help. But as things stands now THP enabled would breaks zone_reclaim_mode and so without hard memory pinning it wouldn't perform as good as with THP disabled. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
