Messages in this thread | | | Date | Thu, 17 Sep 2009 12:18:28 +0100 | From | Mel Gorman <> | Subject | Re: [RFC/PATCH] SLQB: Mark the allocator as broken PowerPC and S390 |
| |
On Thu, Sep 17, 2009 at 02:13:39PM +0300, Pekka Enberg wrote: > Hi Mel, > > On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote: > > The danger is that this isn't a PPC or s390 bug then as such, but a bug where > > there are either memoryless nodes or when node 0 is memoryless. Hence, there > > is no guarantee that your Kconfig option will catch all instances where this > > bug triggers. Granted, the configuration is most likely a PPC machine :) > > Yes, I suggested making SLQB depend on !NUMA to Nick but he didn't like > that as it's known to be good on x86 NUMA configs. >
Agreed.
> On Thu, 2009-09-17 at 11:08 +0100, Mel Gorman wrote: > > > > The danger is if SLQB is being silently disabled, it'll never be noticed > > > > or debugged :/ > > > > > > Maybe, but that's not an excuse to push something that's known to break. > > On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote: > > Wow, this is from back in May! Lame. > > Heh, my (lame) excuse is lack of relevant hardware.... ;-) >
I'm not blaming you. It's just ... unfortunate :/
> On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote: > > I'm against silently disabling it. Memoryless nodes are extremely rare but > > bugs crop up there occasionally and take a long time to catch and squash. SLQB > > breaking there is not going to cause widespread damage but force a fix to > > be developed by the people with access to the affected machines. > > Hey, if someone sends me fix for the bug well before the merge window > closes, that would be great! But there's no way we're adding new core > kernel code that's _known_ to break peoples configs, at least not > through slab.git. If disabling SLQB is not acceptable and we're unable > to fix things, we'll just have to skip this release cycle. >
Please consider disabling it as an option in the rc3 stage or the like. With luck, I'll find a suitable machine in time and see what can be done. I just don't like the idea of x86 defaulting to one allocator and ppc defaulting to another.
> On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote: > > Total aside, does anybody know handily if fake NUMA support allows the > > creation of memoryless nodes help reproducing problems like this? If I can't > > get a real machine, that'll be the approach I'll be trying. > > That would be useful, yes. >
-- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
| |