lkml.org 
[lkml]   [2011]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: ia64 broken by transparent huge pages - other arches too?
    From
    Date
    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




    \
     
     \ /
      Last update: 2011-01-15 17:49    [W:0.022 / U:214.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site