> What everyone else said, plus... > > I worry about the inherit-across-fork thing. A scenario we should > think about is where the user doesn't build his own executables. So he > writes a little wrapper which runs prctl(PR_SET_THP_DISABLED, 0) then > execs the third-party-app. But what happens if that app execs children > who *do* want THP? He has to hunt down and wrap those as well? > > It all seems a bit unwieldy. I wonder if controlling it via the ELF > header would be more practical.
Thanks, Andrew. I'm doing some more testing and looking into using a different method for controlling this. At this point, I think it's fair to say that we don't want to control this using the method that I've proposed here, no matter how we look at it. I've gotten my hands on some of the benchmarks/code that were used to originally uncover the performance issues we're seeing. I'm currently trying to separate out the performance issues that are being caused by the kernel code from issues involving hardware - the cost of remote memory accesses is a bit higher on our systems with node controllers vs. glueless QPI/Hypertransport-based systems. At this point, it's difficult to say whether or not the issue can be solved by "fixing the performance issues with thp," as several have suggested. Don't get me wrong I like the idea of that solution as well; we're just not sure, right now, if that's going to solve all of our problems. I'll be back when I've dug up a bit more info on the issue. Thanks for the input, everyone! -- 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/