[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1303422566.4025.56.camel@mulgrave.site>
Date: Thu, 21 Apr 2011 16:49:26 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: David Rientjes <rientjes@...gle.com>
Cc: Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Pekka Enberg <penberg@...nel.org>,
Michal Hocko <mhocko@...e.cz>, Hugh Dickins <hughd@...gle.com>,
linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
linux-parisc@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH v3] mm: make expand_downwards symmetrical to
expand_upwards
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists