With sparsemem being introduced, we need a central place for new
memory-related .config options: mm/Kconfig. This allows us to
remove many of the duplicated arch-specific options.
The new option, CONFIG_FLATMEM, is there to enable us to detangle
NUMA and DISCONTIGMEM. This is a requirement for sparsemem
because sparsemem uses the NUMA code without the presence of
DISCONTIGMEM. The sparsemem patches use CONFIG_FLATMEM in generic
code, so this patch is a requirement before applying them.
Almost all places that used to do '#ifndef CONFIG_DISCONTIGMEM'
should use '#ifdef CONFIG_FLATMEM' instead.
Signed-off-by: Andy Whitcroft <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
---
memhotplug-dave/mm/Kconfig | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+)
diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
--- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.000000000 -0700
+++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.000000000 -0700
@@ -0,0 +1,25 @@
+choice
+ prompt "Memory model"
+ default FLATMEM
+ default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
+ default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
+
+config FLATMEM
+ bool "Flat Memory"
+ depends on !ARCH_DISCONTIGMEM_ENABLE || ARCH_FLATMEM_ENABLE
+ help
+ This option allows you to change some of the ways that
+ Linux manages its memory internally. Most users will
+ only have one option here: FLATMEM. This is normal
+ and a correct option.
+
+ If unsure, choose this option over any other.
+
+config DISCONTIGMEM
+ bool "Discontigious Memory"
+ depends on ARCH_DISCONTIGMEM_ENABLE
+ help
+ If unsure, choose "Flat Memory" over this option.
+
+endchoice
+
_
On Mon, 2005-04-04 at 16:22 -0700, Mike Kravetz wrote:
> Do you need to set ARCH_DISCONTIGMEM_DEFAULT instead of just
> CONFIG_ARCH_DISCONTIGMEM_ENABLE to have DISCONTIGMEM be the
> default? or am I missing something? I don't see
> ARCH_DISCONTIGMEM_DEFAULT turned on by default in any of these
> patches.
It's a wee bit confusing, but I think it all works out.
Doing ARCH_DISCONTIGMEM_ENABLE=y turns off the FLATMEM option in the
mm/Kconfig prompt because FLATMEM depends on !ARCH_DISCONTIGMEM_ENABLE.
So, if you enable it, it will end up being the default because there's
no other choice.
For configs that *need* both options, you can re-enable FLATMEM with
ARCH_FLATMEM_ENABLE
-- Dave
On Mon, Apr 04, 2005 at 10:50:09AM -0700, Dave Hansen wrote:
diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
--- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.000000000 -0700
+++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.000000000 -0700
@@ -0,0 +1,25 @@
> +choice
> + prompt "Memory model"
> + default FLATMEM
> + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
> + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
> +
Yet the changes to the defconfig files that had DISCONTIGMEM as
the default look like.
-CONFIG_DISCONTIGMEM=y
+CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
Do you need to set ARCH_DISCONTIGMEM_DEFAULT instead of just
CONFIG_ARCH_DISCONTIGMEM_ENABLE to have DISCONTIGMEM be the
default? or am I missing something? I don't see
ARCH_DISCONTIGMEM_DEFAULT turned on by default in any of these
patches.
--
Mike
Hi,
Dave Hansen wrote:
> diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
> --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.000000000 -0700
> +++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.000000000 -0700
> @@ -0,0 +1,25 @@
> +choice
> + prompt "Memory model"
> + default FLATMEM
> + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
> + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
Does this really have to be a user visible option and can't it be
derived from other values? The help text entries are really no help at all.
bye, Roman
On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote:
> Dave Hansen wrote:
> > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.000000000 -0700
> > +++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.000000000 -0700
> > @@ -0,0 +1,25 @@
> > +choice
> > + prompt "Memory model"
> > + default FLATMEM
> > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
> > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
>
> Does this really have to be a user visible option and can't it be
> derived from other values? The help text entries are really no help at all.
I hope that this selection will replace the current DISCONTIGMEM prompts
in the individual architectures. That way, you won't get a net increase
in the number of prompts. However, I do realize that architectures
without DISCONTIG see a new, relatively useless menu/prompt.
Is there a way to hide an entire "choice" menu? If there is, we can
certainly hide it when there's only one possible choice.
-- Dave
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
> On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote:
> > Dave Hansen wrote:
> > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.000000000 -0700
> > > +++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.000000000 -0700
> > > @@ -0,0 +1,25 @@
> > > +choice
> > > + prompt "Memory model"
> > > + default FLATMEM
> > > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
> > > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
> >
> > Does this really have to be a user visible option and can't it be
> > derived from other values? The help text entries are really no help at all.
>
> I hope that this selection will replace the current DISCONTIGMEM prompts
> in the individual architectures. That way, you won't get a net increase
> in the number of prompts.
Why is this choice needed at all? Why would one choose SPARSEMEM over
DISCONTIGMEM? Help texts such as "If unsure, choose <something else>" make
the complete config option pretty useless.
bye, Roman
On Thu, 2005-04-07 at 01:40 +0200, Roman Zippel wrote:
> On Wed, 6 Apr 2005, Dave Hansen wrote:
> > On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote:
> > > Dave Hansen wrote:
> > > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.000000000 -0700
> > > > +++ memhotplug-dave/mm/Kconfig 2005-04-04 10:15:23.000000000 -0700
> > > > @@ -0,0 +1,25 @@
> > > > +choice
> > > > + prompt "Memory model"
> > > > + default FLATMEM
> > > > + default SPARSEMEM if ARCH_SPARSEMEM_DEFAULT
> > > > + default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT
> > >
> > > Does this really have to be a user visible option and can't it be
> > > derived from other values? The help text entries are really no help at all.
> >
> > I hope that this selection will replace the current DISCONTIGMEM prompts
> > in the individual architectures. That way, you won't get a net increase
> > in the number of prompts.
>
> Why is this choice needed at all? Why would one choose SPARSEMEM over
> DISCONTIGMEM?
For now, it's only so people can test either one, and we don't have to
try to toss DICONTIGMEM out of the kernel in fell swoop. When the
memory hotplug options are enabled, the DISCONTIG option goes away, and
SPARSEMEM is selected as the only option.
I hope to, in the future, make the options more like this:
config MEMORY_HOTPLUG...
config NUMA...
config DISCONTIGMEM
depends on NUMA && !MEMORY_HOTPLUG
config SPARSEMEM
depends on MEMORY_HOTPLUG || OTHER_ARCH_THING
config FLATMEM
depends on !DISCONTIGMEM && !SPARSEMEM
So, if they enable NUMA, they get DISCONTIGMEM automatically. If they
enable MEMORY_HOTPLUG on top of that, they automatically get SPARSEMEM
instead. All of the complex "pick your memory model" stuff goes away,
and you just select features. However, I think the current situation is
a reasonable intermediate step, as we need to be able to switch back and
forth for now.
> Help texts such as "If unsure, choose <something else>" make
> the complete config option pretty useless.
They don't make it useless, they just guide a clueless user to the right
place, without them having to think about it at all. Those of us that
need to test the various configurations are quite sure of what we're
doing, and can ignore the messages. :)
I'm not opposed to creating some better help text for those things, I'm
just not sure that we really need it, or that it will help end users get
to the right place. I guess more explanation never hurt anyone.
-- Dave
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
> > Why is this choice needed at all? Why would one choose SPARSEMEM over
> > DISCONTIGMEM?
>
> For now, it's only so people can test either one, and we don't have to
> try to toss DICONTIGMEM out of the kernel in fell swoop. When the
> memory hotplug options are enabled, the DISCONTIG option goes away, and
> SPARSEMEM is selected as the only option.
>
> I hope to, in the future, make the options more like this:
>
> config MEMORY_HOTPLUG...
> config NUMA...
>
> config DISCONTIGMEM
> depends on NUMA && !MEMORY_HOTPLUG
>
> config SPARSEMEM
> depends on MEMORY_HOTPLUG || OTHER_ARCH_THING
>
> config FLATMEM
> depends on !DISCONTIGMEM && !SPARSEMEM
I was hoping for this too, in the meantime can't you simply make it a
suboption of DISCONTIGMEM? So an extra option is only visible when it's
enabled and most people can ignore it completely by just disabling a
single option.
> > Help texts such as "If unsure, choose <something else>" make
> > the complete config option pretty useless.
>
> They don't make it useless, they just guide a clueless user to the right
> place, without them having to think about it at all. Those of us that
> need to test the various configurations are quite sure of what we're
> doing, and can ignore the messages. :)
>
> I'm not opposed to creating some better help text for those things, I'm
> just not sure that we really need it, or that it will help end users get
> to the right place. I guess more explanation never hurt anyone.
Some basic explanation with a link for more information can't hurt.
bye, Roman
On Thu, 2005-04-07 at 02:30 +0200, Roman Zippel wrote:
> I was hoping for this too, in the meantime can't you simply make it a
> suboption of DISCONTIGMEM? So an extra option is only visible when it's
> enabled and most people can ignore it completely by just disabling a
> single option.
That's reasonable, except that SPARSEMEM doesn't strictly have anything
to do with DISCONTIG.
How about a menu that's hidden under CONFIG_EXPERIMENTAL?
> > I'm not opposed to creating some better help text for those things, I'm
> > just not sure that we really need it, or that it will help end users get
> > to the right place. I guess more explanation never hurt anyone.
>
> Some basic explanation with a link for more information can't hurt.
I'll see what I can come up with.
-- Dave
Hi Roman,
How does the attached patch look? It will still give us the flexibility
to override the memory models, but only in the presence of
CONFIG_EXPERIMENTAL.
It also adds some better help text to the DISCONTIGMEM menu. Is that
something like what you were looking for?
-- Dave