Re: [PATCHv2] Add per-process flag to control thp

[Alex Thorlton <athorlton@sgi.com>]

> 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!