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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
