Re: ia64 broken by transparent huge pages - other arches too?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2011-01-15 at 16:59 +0100, Andrea Arcangeli wrote:
> On Sat, Jan 15, 2011 at 06:21:36PM +1100, Benjamin Herrenschmidt wrote:
> > This is insane. Having such a massively invasive change to the whole mm,
> > barely tested on most architecture, and last I heard still generally
> > controversial being merged like that without even some integration
> > testing via -next makes no sense.
> 
> This is 99% a noop for all archs but x86.. Really if you worry about
> the testing you should worry about x86 only! Only x86 is affected by
> the brainer part of the code, and only if TRANSPARENT_HUGEPAGE=y
> (which is set to N by default).
> 
> Not x86 archs can't possibly have a regression because of this. The
> reason there's this compile trouble is that I cleaned up some bad code
> in include/asm-generic/pgtable.h while adding the pmd methods, and I
> tried to keep everything as a static inline as requested by Mel for
> better gcc compile time validation than what the preprocessor can
> do. Otherwise if it was a macro I may not have had to return
> anything and I could just BUG() in this pmd method that requires the
> __pmd macro to be implemented by all archs (I think it's better off if
> __pmd is available considering __pte seems already available).
> 
> The below can't introduce regressions, if it builds it'll work, so the
> testing on -next for the other archs isn't really necessary at all. I
> don't think you can worry about a one liner change to make ia64 build,
> when the brainer part of the code is a noop for the other archs
> (including x86 when the config option is off).

Andrea, what you say above isn't true, you're not thinking broadly
enough: the kernel is a complex set of code interactions.  For instance,
you caused this build break on parisc (which is a regression even though
parisc has no transparent huge pages at all):

http://marc.info/?l=linux-arch&m=129504371532124

That was just from a simple code rearrangement (independent of any of
the config options).

One of the points of getting stuff through linux-next is that all of
these problems get sorted out long before the code hits mainline.  This
happens because linux-next gets a wide range of config randomisation
testing plus quite a few different architecture builds and runs.

The problem is very often not in the actual code, but in the side
effects the code causes.  This is what linux-next integration helps
mitigate. So, please use it next time.  Just testing on x86 in your own
configuration isn't sufficient to pick up the problems.

James