Re: [PATCH v3] mm: make expand_downwards symmetrical toexpand_upwards
From: James Bottomley
Date: Thu Apr 21 2011 - 17:49:43 EST
On Thu, 2011-04-21 at 14:34 -0700, David Rientjes wrote:
> On Thu, 21 Apr 2011, James Bottomley wrote:
>
> > > - parisc: James has already queued "parisc: set memory ranges in
> > > N_NORMAL_MEMORY when onlined" for 2.6.39, so all he needs now is
> > > to merge a hybrid of the Kconfig changes requiring CONFIG_NUMA for
> > > CONFIG_DISCONTIGMEM from KOSAKI-san and myself which also fix the
> > > compile issues,
> >
> > Not quite: if we go this route, we need to sort out our CPU scheduling
> > problem as well ... as I said, I don't think we've got all the necessary
> > numa machinery in place yet.
> >
>
> Ok, it seems like there're two options for this release cycle:
>
> (1) merge the patch that enables CONFIG_NUMA for DISCONTIGMEM but only
> do so if CONFIG_SLUB is enabled to avoid the build error, or
That's not an option without coming up with the rest of the numa
fixes ... we can't basically force all SMP systems to become UP.
What build error, by the way? There's only a runtime panic caused by
slub.
> (2) disallow CONFIG_SLUB for parisc with DISCONTIGMEM.
Well, that's this patch ... it will actually fix every architecture, not
just parisc.
> diff --git a/init/Kconfig b/init/Kconfig
> index 56240e7..a7ad8fb 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1226,6 +1226,7 @@ config SLAB
> per cpu and per node queues.
>
> config SLUB
> + depends on BROKEN || NUMA || !DISCONTIGMEM
> bool "SLUB (Unqueued Allocator)"
> help
> SLUB is a slab allocator that minimizes cache line usage
I already sent it to linux-arch and there's been no dissent; there have
been a few "will that fix my slub bug?" type of responses.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/