2005-06-23 07:07:49 +00:00
|
|
|
config SELECT_MEMORY_MODEL
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL
|
|
|
|
|
|
2005-06-23 07:07:42 +00:00
|
|
|
choice
|
|
|
|
|
prompt "Memory model"
|
2005-06-23 07:07:49 +00:00
|
|
|
depends on SELECT_MEMORY_MODEL
|
|
|
|
|
default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
default SPARSEMEM_MANUAL if ARCH_SPARSEMEM_DEFAULT
|
2005-06-23 07:07:49 +00:00
|
|
|
default FLATMEM_MANUAL
|
2005-06-23 07:07:42 +00:00
|
|
|
|
2005-06-23 07:07:49 +00:00
|
|
|
config FLATMEM_MANUAL
|
2005-06-23 07:07:42 +00:00
|
|
|
bool "Flat Memory"
|
2006-01-06 08:12:07 +00:00
|
|
|
depends on !(ARCH_DISCONTIGMEM_ENABLE || ARCH_SPARSEMEM_ENABLE) || ARCH_FLATMEM_ENABLE
|
2005-06-23 07:07:42 +00:00
|
|
|
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.
|
|
|
|
|
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
Some users of more advanced features like NUMA and
|
|
|
|
|
memory hotplug may have different options here.
|
|
|
|
|
DISCONTIGMEM is an more mature, better tested system,
|
|
|
|
|
but is incompatible with memory hotplug and may suffer
|
|
|
|
|
decreased performance over SPARSEMEM. If unsure between
|
|
|
|
|
"Sparse Memory" and "Discontiguous Memory", choose
|
|
|
|
|
"Discontiguous Memory".
|
|
|
|
|
|
|
|
|
|
If unsure, choose this option (Flat Memory) over any other.
|
2005-06-23 07:07:42 +00:00
|
|
|
|
2005-06-23 07:07:49 +00:00
|
|
|
config DISCONTIGMEM_MANUAL
|
2005-09-17 02:27:54 +00:00
|
|
|
bool "Discontiguous Memory"
|
2005-06-23 07:07:42 +00:00
|
|
|
depends on ARCH_DISCONTIGMEM_ENABLE
|
|
|
|
|
help
|
2005-06-23 07:07:50 +00:00
|
|
|
This option provides enhanced support for discontiguous
|
|
|
|
|
memory systems, over FLATMEM. These systems have holes
|
|
|
|
|
in their physical address spaces, and this option provides
|
|
|
|
|
more efficient handling of these holes. However, the vast
|
|
|
|
|
majority of hardware has quite flat address spaces, and
|
|
|
|
|
can have degraded performance from extra overhead that
|
|
|
|
|
this option imposes.
|
|
|
|
|
|
|
|
|
|
Many NUMA configurations will have this as the only option.
|
|
|
|
|
|
2005-06-23 07:07:42 +00:00
|
|
|
If unsure, choose "Flat Memory" over this option.
|
|
|
|
|
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
config SPARSEMEM_MANUAL
|
|
|
|
|
bool "Sparse Memory"
|
|
|
|
|
depends on ARCH_SPARSEMEM_ENABLE
|
|
|
|
|
help
|
|
|
|
|
This will be the only option for some systems, including
|
|
|
|
|
memory hotplug systems. This is normal.
|
|
|
|
|
|
|
|
|
|
For many other systems, this will be an alternative to
|
2005-09-17 02:27:54 +00:00
|
|
|
"Discontiguous Memory". This option provides some potential
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
performance benefits, along with decreased code complexity,
|
|
|
|
|
but it is newer, and more experimental.
|
|
|
|
|
|
|
|
|
|
If unsure, choose "Discontiguous Memory" or "Flat Memory"
|
|
|
|
|
over this option.
|
|
|
|
|
|
2005-06-23 07:07:42 +00:00
|
|
|
endchoice
|
|
|
|
|
|
2005-06-23 07:07:49 +00:00
|
|
|
config DISCONTIGMEM
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL
|
|
|
|
|
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
config SPARSEMEM
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on SPARSEMEM_MANUAL
|
|
|
|
|
|
2005-06-23 07:07:49 +00:00
|
|
|
config FLATMEM
|
|
|
|
|
def_bool y
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
depends on (!DISCONTIGMEM && !SPARSEMEM) || FLATMEM_MANUAL
|
|
|
|
|
|
|
|
|
|
config FLAT_NODE_MEM_MAP
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on !SPARSEMEM
|
2005-06-23 07:07:49 +00:00
|
|
|
|
2005-06-23 07:07:47 +00:00
|
|
|
#
|
|
|
|
|
# Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's
|
|
|
|
|
# to represent different areas of memory. This variable allows
|
|
|
|
|
# those dependencies to exist individually.
|
|
|
|
|
#
|
|
|
|
|
config NEED_MULTIPLE_NODES
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on DISCONTIGMEM || NUMA
|
2005-06-23 07:07:53 +00:00
|
|
|
|
|
|
|
|
config HAVE_MEMORY_PRESENT
|
|
|
|
|
def_bool y
|
[PATCH] sparsemem memory model
Sparsemem abstracts the use of discontiguous mem_maps[]. This kind of
mem_map[] is needed by discontiguous memory machines (like in the old
CONFIG_DISCONTIGMEM case) as well as memory hotplug systems. Sparsemem
replaces DISCONTIGMEM when enabled, and it is hoped that it can eventually
become a complete replacement.
A significant advantage over DISCONTIGMEM is that it's completely separated
from CONFIG_NUMA. When producing this patch, it became apparent in that NUMA
and DISCONTIG are often confused.
Another advantage is that sparse doesn't require each NUMA node's ranges to be
contiguous. It can handle overlapping ranges between nodes with no problems,
where DISCONTIGMEM currently throws away that memory.
Sparsemem uses an array to provide different pfn_to_page() translations for
each SECTION_SIZE area of physical memory. This is what allows the mem_map[]
to be chopped up.
In order to do quick pfn_to_page() operations, the section number of the page
is encoded in page->flags. Part of the sparsemem infrastructure enables
sharing of these bits more dynamically (at compile-time) between the
page_zone() and sparsemem operations. However, on 32-bit architectures, the
number of bits is quite limited, and may require growing the size of the
page->flags type in certain conditions. Several things might force this to
occur: a decrease in the SECTION_SIZE (if you want to hotplug smaller areas of
memory), an increase in the physical address space, or an increase in the
number of used page->flags.
One thing to note is that, once sparsemem is present, the NUMA node
information no longer needs to be stored in the page->flags. It might provide
speed increases on certain platforms and will be stored there if there is
room. But, if out of room, an alternate (theoretically slower) mechanism is
used.
This patch introduces CONFIG_FLATMEM. It is used in almost all cases where
there used to be an #ifndef DISCONTIG, because SPARSEMEM and DISCONTIGMEM
often have to compile out the same areas of code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Martin Bligh <mbligh@aracnet.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 07:07:54 +00:00
|
|
|
depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
|
2005-09-03 22:54:26 +00:00
|
|
|
|
2005-09-03 22:54:28 +00:00
|
|
|
#
|
|
|
|
|
# SPARSEMEM_EXTREME (which is the default) does some bootmem
|
2006-10-03 20:53:09 +00:00
|
|
|
# allocations when memory_present() is called. If this cannot
|
2005-09-03 22:54:28 +00:00
|
|
|
# be done on your architecture, select this option. However,
|
|
|
|
|
# statically allocating the mem_section[] array can potentially
|
|
|
|
|
# consume vast quantities of .bss, so be careful.
|
|
|
|
|
#
|
|
|
|
|
# This option will also potentially produce smaller runtime code
|
|
|
|
|
# with gcc 3.4 and later.
|
|
|
|
|
#
|
|
|
|
|
config SPARSEMEM_STATIC
|
|
|
|
|
def_bool n
|
|
|
|
|
|
2005-09-03 22:54:26 +00:00
|
|
|
#
|
2006-10-03 20:34:14 +00:00
|
|
|
# Architecture platforms which require a two level mem_section in SPARSEMEM
|
2005-09-03 22:54:26 +00:00
|
|
|
# must select this option. This is usually for architecture platforms with
|
|
|
|
|
# an extremely sparse physical address space.
|
|
|
|
|
#
|
2005-09-03 22:54:28 +00:00
|
|
|
config SPARSEMEM_EXTREME
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on SPARSEMEM && !SPARSEMEM_STATIC
|
[PATCH] mm: split page table lock
Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
a many-threaded application which concurrently initializes different parts of
a large anonymous area.
This patch corrects that, by using a separate spinlock per page table page, to
guard the page table entries in that page, instead of using the mm's single
page_table_lock. (But even then, page_table_lock is still used to guard page
table allocation, and anon_vma allocation.)
In this implementation, the spinlock is tucked inside the struct page of the
page table page: with a BUILD_BUG_ON in case it overflows - which it would in
the case of 32-bit PA-RISC with spinlock debugging enabled.
Splitting the lock is not quite for free: another cacheline access. Ideally,
I suppose we would use split ptlock only for multi-threaded processes on
multi-cpu machines; but deciding that dynamically would have its own costs.
So for now enable it by config, at some number of cpus - since the Kconfig
language doesn't support inequalities, let preprocessor compare that with
NR_CPUS. But I don't think it's worth being user-configurable: for good
testing of both split and unsplit configs, split now at 4 cpus, and perhaps
change that to 8 later.
There is a benefit even for singly threaded processes: kswapd can be attacking
one part of the mm while another part is busy faulting.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 01:16:40 +00:00
|
|
|
|
2007-10-16 08:24:14 +00:00
|
|
|
#
|
|
|
|
|
# SPARSEMEM_VMEMMAP uses a virtually mapped mem_map to optimise pfn_to_page
|
|
|
|
|
# and page_to_pfn. The most efficient option where kernel virtual space is
|
|
|
|
|
# not under pressure.
|
|
|
|
|
#
|
|
|
|
|
config SPARSEMEM_VMEMMAP_ENABLE
|
|
|
|
|
def_bool n
|
|
|
|
|
|
|
|
|
|
config SPARSEMEM_VMEMMAP
|
|
|
|
|
bool
|
|
|
|
|
depends on SPARSEMEM
|
|
|
|
|
default y if (SPARSEMEM_VMEMMAP_ENABLE)
|
|
|
|
|
|
2005-10-30 01:16:54 +00:00
|
|
|
# eventually, we can have this option just 'select SPARSEMEM'
|
|
|
|
|
config MEMORY_HOTPLUG
|
|
|
|
|
bool "Allow for memory hot-add"
|
2006-10-01 06:27:05 +00:00
|
|
|
depends on SPARSEMEM || X86_64_ACPI_NUMA
|
2007-07-29 21:24:36 +00:00
|
|
|
depends on HOTPLUG && !HIBERNATION && ARCH_ENABLE_MEMORY_HOTPLUG
|
2007-06-07 02:32:52 +00:00
|
|
|
depends on (IA64 || X86 || PPC64 || SUPERH)
|
2005-10-30 01:16:54 +00:00
|
|
|
|
|
|
|
|
comment "Memory hotplug is currently incompatible with Software Suspend"
|
2007-07-29 21:24:36 +00:00
|
|
|
depends on SPARSEMEM && HOTPLUG && HIBERNATION
|
2005-10-30 01:16:54 +00:00
|
|
|
|
2006-10-01 06:27:05 +00:00
|
|
|
config MEMORY_HOTPLUG_SPARSE
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on SPARSEMEM && MEMORY_HOTPLUG
|
|
|
|
|
|
[PATCH] mm: split page table lock
Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
a many-threaded application which concurrently initializes different parts of
a large anonymous area.
This patch corrects that, by using a separate spinlock per page table page, to
guard the page table entries in that page, instead of using the mm's single
page_table_lock. (But even then, page_table_lock is still used to guard page
table allocation, and anon_vma allocation.)
In this implementation, the spinlock is tucked inside the struct page of the
page table page: with a BUILD_BUG_ON in case it overflows - which it would in
the case of 32-bit PA-RISC with spinlock debugging enabled.
Splitting the lock is not quite for free: another cacheline access. Ideally,
I suppose we would use split ptlock only for multi-threaded processes on
multi-cpu machines; but deciding that dynamically would have its own costs.
So for now enable it by config, at some number of cpus - since the Kconfig
language doesn't support inequalities, let preprocessor compare that with
NR_CPUS. But I don't think it's worth being user-configurable: for good
testing of both split and unsplit configs, split now at 4 cpus, and perhaps
change that to 8 later.
There is a benefit even for singly threaded processes: kswapd can be attacking
one part of the mm while another part is busy faulting.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 01:16:40 +00:00
|
|
|
# Heavily threaded applications may benefit from splitting the mm-wide
|
|
|
|
|
# page_table_lock, so that faults on different parts of the user address
|
|
|
|
|
# space can be handled with less contention: split it at this NR_CPUS.
|
|
|
|
|
# Default to 4 for wider testing, though 8 might be more appropriate.
|
|
|
|
|
# ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
|
2005-11-23 21:37:37 +00:00
|
|
|
# PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
|
[PATCH] mm: split page table lock
Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
a many-threaded application which concurrently initializes different parts of
a large anonymous area.
This patch corrects that, by using a separate spinlock per page table page, to
guard the page table entries in that page, instead of using the mm's single
page_table_lock. (But even then, page_table_lock is still used to guard page
table allocation, and anon_vma allocation.)
In this implementation, the spinlock is tucked inside the struct page of the
page table page: with a BUILD_BUG_ON in case it overflows - which it would in
the case of 32-bit PA-RISC with spinlock debugging enabled.
Splitting the lock is not quite for free: another cacheline access. Ideally,
I suppose we would use split ptlock only for multi-threaded processes on
multi-cpu machines; but deciding that dynamically would have its own costs.
So for now enable it by config, at some number of cpus - since the Kconfig
language doesn't support inequalities, let preprocessor compare that with
NR_CPUS. But I don't think it's worth being user-configurable: for good
testing of both split and unsplit configs, split now at 4 cpus, and perhaps
change that to 8 later.
There is a benefit even for singly threaded processes: kswapd can be attacking
one part of the mm while another part is busy faulting.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 01:16:40 +00:00
|
|
|
#
|
|
|
|
|
config SPLIT_PTLOCK_CPUS
|
|
|
|
|
int
|
|
|
|
|
default "4096" if ARM && !CPU_CACHE_VIPT
|
2005-11-23 21:37:37 +00:00
|
|
|
default "4096" if PARISC && !PA20
|
2007-10-06 00:19:35 +00:00
|
|
|
default "4096" if XEN
|
[PATCH] mm: split page table lock
Christoph Lameter demonstrated very poor scalability on the SGI 512-way, with
a many-threaded application which concurrently initializes different parts of
a large anonymous area.
This patch corrects that, by using a separate spinlock per page table page, to
guard the page table entries in that page, instead of using the mm's single
page_table_lock. (But even then, page_table_lock is still used to guard page
table allocation, and anon_vma allocation.)
In this implementation, the spinlock is tucked inside the struct page of the
page table page: with a BUILD_BUG_ON in case it overflows - which it would in
the case of 32-bit PA-RISC with spinlock debugging enabled.
Splitting the lock is not quite for free: another cacheline access. Ideally,
I suppose we would use split ptlock only for multi-threaded processes on
multi-cpu machines; but deciding that dynamically would have its own costs.
So for now enable it by config, at some number of cpus - since the Kconfig
language doesn't support inequalities, let preprocessor compare that with
NR_CPUS. But I don't think it's worth being user-configurable: for good
testing of both split and unsplit configs, split now at 4 cpus, and perhaps
change that to 8 later.
There is a benefit even for singly threaded processes: kswapd can be attacking
one part of the mm while another part is busy faulting.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-30 01:16:40 +00:00
|
|
|
default "4"
|
2006-01-08 09:00:49 +00:00
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# support for page migration
|
|
|
|
|
#
|
|
|
|
|
config MIGRATION
|
2006-03-22 08:09:12 +00:00
|
|
|
bool "Page migration"
|
2006-06-23 09:03:37 +00:00
|
|
|
def_bool y
|
|
|
|
|
depends on NUMA
|
2006-03-22 08:09:12 +00:00
|
|
|
help
|
|
|
|
|
Allows the migration of the physical location of pages of processes
|
|
|
|
|
while the virtual addresses are not changed. This is useful for
|
|
|
|
|
example on NUMA systems to put pages nearer to the processors accessing
|
|
|
|
|
the page.
|
2006-06-13 00:11:31 +00:00
|
|
|
|
|
|
|
|
config RESOURCES_64BIT
|
|
|
|
|
bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT && EXPERIMENTAL)
|
|
|
|
|
default 64BIT
|
|
|
|
|
help
|
|
|
|
|
This option allows memory and IO resources to be 64 bit.
|
2007-02-10 09:43:10 +00:00
|
|
|
|
|
|
|
|
config ZONE_DMA_FLAG
|
|
|
|
|
int
|
|
|
|
|
default "0" if !ZONE_DMA
|
|
|
|
|
default "1"
|
|
|
|
|
|
2007-07-17 11:03:37 +00:00
|
|
|
config BOUNCE
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
|
|
|
|
|
|
2007-05-06 21:49:50 +00:00
|
|
|
config NR_QUICK
|
|
|
|
|
int
|
|
|
|
|
depends on QUICKLIST
|
2007-05-14 00:55:35 +00:00
|
|
|
default "2" if (SUPERH && !SUPERH64)
|
2007-05-06 21:49:50 +00:00
|
|
|
default "1"
|
2007-07-16 06:40:05 +00:00
|
|
|
|
|
|
|
|
config VIRT_TO_BUS
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on !ARCH_NO_VIRT_TO_BUS
|
