From: Bob Picco <bob.picco@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH 0/4] V4 ia64 SPARSEMEM
Date: Tue, 27 Sep 2005 19:22:43 +0000 [thread overview]
Message-ID: <20050927192243.GU16066@localhost.localdomain> (raw)
In-Reply-To: <20050922161418.GW16066@localhost.localdomain>
Bob Picco wrote: [Tue Sep 27 2005, 10:09:20AM EDT]
> luck wrote: [Mon Sep 26 2005, 08:03:09PM EDT]
> > >I'm assuming you refer to the config changes in arch/ia64/Kconfig. Well the
> > >new ones are documented in mm/Kconfig. If that documentation is inadequate,
> > >then I can attempt to supply more.
> >
> > There aren't any words in there about why I might want to use
> > sparsemem ... just a standard version of if you don't know what
> > to pick, go with the old discontig stuff.
> I can't say there is disagreement with this point. So you'd obviously like
> more help text in mm/Kconfig?
> >
> >
> > >Should you think we won't get sufficient test converage without some default
> > >configuration files, then I'd suggest the two mentioned about be introduced.
> >
> > This is definitely the prime issue ... config space on ia64
> > is already very fragmented, so testting of some combination
> > of options is rare to non-existant. If SPARSEMEM isn't turned
> > on, then it won't be used by anyone that isn't already reading
> > the lhms list. Coupled with the lack of sales pitch in the
> > Kconfig help files, it looks like this isn't going to be used
> > by anyone!
> Yep. I thought this is what you are after.
> >
> > >Long term should SPARSEMEM become the default and DISCONTIG+VIRTUAL_MEM_MAP
> > >be obsoleted then we could remove the config files.
> >
> > If benchmarks show no difference, then I'll consolidate the
> > configuration options. I still think that VIRTUAL_MEM_MAP
> > has a great deal of elegance to it ... auto-sizing to just
> > about any degree of sparseness, but I think we need to
> > simplify.
> Well I'm not attempting to be critical of VIRTUAL_MEM_MAP. Obviously it
> satisfies a solution which was previously unanswered. I'm just hoping to reduce
> our configuration options. We aren't even remotely close to possibly
> considering this.
> >
> The bigsur problem isn't nodedata.h related. It's in arch/ia64/Kconfig which
> figures. I should have this resolved some time today after checking
> the default configs.
> > -Tony
> > -
> bob
Okay. There was a bug in my Kconfig. All defconfigs and my own memory model
configs build correctly and produce the correct config options. Below is
a replacement for patch 1/4 which I've included for your config testing. I'll
post V5 patchset when we agree on where we want to proceed with config(s).
I'm thinking all we need is sparsemem_defconfig which is defconfig but with
the SPARSEMEM memory model.
thanks,
bob
arch/ia64/Kconfig | 94 +++++++++++++++++++++++++++++---------------------
arch/ia64/mm/Makefile | 5 +-
2 files changed, 58 insertions(+), 41 deletions(-)
Index: linux-2.6.14-rc2/arch/ia64/Kconfig
=================================--- linux-2.6.14-rc2.orig/arch/ia64/Kconfig 2005-09-26 19:16:57.000000000 -0400
+++ linux-2.6.14-rc2/arch/ia64/Kconfig 2005-09-27 14:31:21.000000000 -0400
@@ -63,8 +63,6 @@ config IA64_GENERIC
select ACPI
select NUMA
select ACPI_NUMA
- select VIRTUAL_MEM_MAP
- select DISCONTIGMEM
help
This selects the system type of your hardware. A "generic" kernel
will run on any supported IA-64 system. However, if you configure
@@ -176,40 +174,6 @@ config IA64_L1_CACHE_SHIFT
default "6" if ITANIUM
# align cache-sensitive data to 64 bytes
-config NUMA
- bool "NUMA support"
- depends on !IA64_HP_SIM
- default y if IA64_SGI_SN2
- select ACPI_NUMA
- help
- Say Y to compile the kernel to support NUMA (Non-Uniform Memory
- Access). This option is for configuring high-end multiprocessor
- server systems. If in doubt, say N.
-
-config VIRTUAL_MEM_MAP
- bool "Virtual mem map"
- default y if !IA64_HP_SIM
- help
- Say Y to compile the kernel with support for a virtual mem map.
- This code also only takes effect if a memory hole of greater than
- 1 Gb is found during boot. You must turn this option on if you
- require the DISCONTIGMEM option for your machine. If you are
- unsure, say Y.
-
-config HOLES_IN_ZONE
- bool
- default y if VIRTUAL_MEM_MAP
-
-config ARCH_DISCONTIGMEM_ENABLE
- bool "Discontiguous memory support"
- depends on (IA64_DIG || IA64_SGI_SN2 || IA64_GENERIC || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB) && NUMA && VIRTUAL_MEM_MAP
- default y if (IA64_SGI_SN2 || IA64_GENERIC) && NUMA
- help
- Say Y to support efficient handling of discontiguous physical memory,
- for architectures which are either NUMA (Non-Uniform Memory Access)
- or have huge holes in the physical address space for other reasons.
- See <file:Documentation/vm/numa> for more.
-
config IA64_CYCLONE
bool "Cyclone (EXA) Time Source support"
help
@@ -232,8 +196,10 @@ config IA64_SGI_SN_XP
based on a network adapter and DMA messaging.
config FORCE_MAX_ZONEORDER
- int
- default "18"
+ int "MAX_ORDER (11 - 17)" if !HUGETLB_PAGE
+ range 11 17 if !HUGETLB_PAGE
+ default "17" if HUGETLB_PAGE
+ default "11"
config SMP
bool "Symmetric multi-processing support"
@@ -298,6 +264,58 @@ config PREEMPT
source "mm/Kconfig"
+config ARCH_SELECT_MEMORY_MODEL
+ def_bool y
+
+config ARCH_DISCONTIGMEM_ENABLE
+ def_bool y
+ help
+ Say Y to support efficient handling of discontiguous physical memory,
+ for architectures which are either NUMA (Non-Uniform Memory Access)
+ or have huge holes in the physical address space for other reasons.
+ See <file:Documentation/vm/numa> for more.
+
+config ARCH_FLATMEM_ENABLE
+ def_bool y
+
+config ARCH_SPARSEMEM_ENABLE
+ def_bool y
+ depends on ARCH_DISCONTIGMEM_ENABLE
+
+config ARCH_DISCONTIGMEM_DEFAULT
+ def_bool y if (IA64_SGI_SN2 || IA64_GENERIC || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB)
+ depends on ARCH_DISCONTIGMEM_ENABLE
+
+config NUMA
+ bool "NUMA support"
+ depends on !IA64_HP_SIM && !FLATMEM
+ default y if IA64_SGI_SN2
+ help
+ Say Y to compile the kernel to support NUMA (Non-Uniform Memory
+ Access). This option is for configuring high-end multiprocessor
+ server systems. If in doubt, say N.
+
+# VIRTUAL_MEM_MAP and FLAT_NODE_MEM_MAP are functionally equivalent.
+# VIRTUAL_MEM_MAP has been retained for historical reasons.
+config VIRTUAL_MEM_MAP
+ bool "Virtual mem map"
+ depends on !SPARSEMEM
+ default y if !IA64_HP_SIM
+ help
+ Say Y to compile the kernel with support for a virtual mem map.
+ This code also only takes effect if a memory hole of greater than
+ 1 Gb is found during boot. You must turn this option on if you
+ require the DISCONTIGMEM option for your machine. If you are
+ unsure, say Y.
+
+config HOLES_IN_ZONE
+ bool
+ default y if VIRTUAL_MEM_MAP
+
+config HAVE_ARCH_EARLY_PFN_TO_NID
+ def_bool y
+ depends on NEED_MULTIPLE_NODES
+
config IA32_SUPPORT
bool "Support for Linux/x86 binaries"
help
Index: linux-2.6.14-rc2/arch/ia64/mm/Makefile
=================================--- linux-2.6.14-rc2.orig/arch/ia64/mm/Makefile 2005-09-26 19:16:57.000000000 -0400
+++ linux-2.6.14-rc2/arch/ia64/mm/Makefile 2005-09-26 19:49:27.000000000 -0400
@@ -7,6 +7,5 @@ obj-y := init.o fault.o tlb.o extable.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_DISCONTIGMEM) += discontig.o
-ifndef CONFIG_DISCONTIGMEM
-obj-y += contig.o
-endif
+obj-$(CONFIG_SPARSEMEM) += discontig.o
+obj-$(CONFIG_FLATMEM) += contig.o
next prev parent reply other threads:[~2005-09-27 19:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-22 16:14 [PATCH 0/4] V4 ia64 SPARSEMEM Bob Picco
2005-09-26 20:40 ` Luck, Tony
2005-09-26 22:23 ` Luck, Tony
2005-09-26 23:35 ` Bob Picco
2005-09-26 23:40 ` Bob Picco
2005-09-27 0:03 ` Luck, Tony
2005-09-27 1:20 ` David Mosberger-Tang
2005-09-27 4:53 ` Yasunori Goto
2005-09-27 12:45 ` Jack Steiner
2005-09-27 14:09 ` Bob Picco
2005-09-27 14:10 ` Bob Picco
2005-09-27 19:22 ` Bob Picco [this message]
2005-09-27 22:00 ` Luck, Tony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050927192243.GU16066@localhost.localdomain \
--to=bob.picco@hp.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.