On Tue 23-04-13 12:22:34, Han Pingtian wrote: > On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote: > > > CONFIG_PPC_BOOK3S_64=y > > > # CONFIG_PPC_BOOK3E_64 is not set > > > -CONFIG_GENERIC_CPU=y > > > +# CONFIG_GENERIC_CPU is not set > > > # CONFIG_CELL_CPU is not set > > > # CONFIG_POWER4_CPU is not set > > > # CONFIG_POWER5_CPU is not set > > > # CONFIG_POWER6_CPU is not set > > > -# CONFIG_POWER7_CPU is not set > > > +CONFIG_POWER7_CPU=y > > > > Wow, so the two configs are for different architectures? Not very much > > helpful. Could you stick with a single machine and do just small updates > > to the config to the point where the problem is no longer present, > > please? > > > No, both configs are for power system. I changed it to > 'CONFIG_POWER7_CPU' by myself in the good one. I think this difference > doesn't matter here.
Ohh, good, I thought it was a x86 thingy. Sorry about the confusion. No other arch does that... > > [...] > > > -CONFIG_SLUB_DEBUG=y > > > -# CONFIG_COMPAT_BRK is not set > > > -# CONFIG_SLAB is not set > > > -CONFIG_SLUB=y > > > +CONFIG_COMPAT_BRK=y > > > +CONFIG_SLAB=y > > > > I would start with the bad config and SLUB changed to SLAB in the first > > step, though. > > > Yep, after I changed bad config to use SLAB, the problem disppears after > using the new kernel. Looks like something wrong in SLUB? It seems so or maybe there is a different issue which is just made visible by SLUB or it is an arch specific problem. What is the workload that triggers this behavior? Can you reduce it to a minimum test case? I guess that you are still testing with vanilla 3.9-rc? kernel without any additional patches or 3rd party modules, right? -- Michal Hocko SUSE Labs -- 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/