Re: [RFC/PATCH] SLQB: Mark the allocator as broken PowerPC and S390

[Pekka Enberg <penberg@cs.helsinki.fi>]

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.

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.... ;-)

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.

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.

			Pekka