From: Dave Hansen <dave@sr71.net>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, Dave Hansen <dave@sr71.net>
Subject: [PATCH 03/12] x86 Kconfig: move highmem
Date: Mon, 13 Jan 2014 11:22:49 -0800 [thread overview]
Message-ID: <20140113192249.3A34B048@viggo.jf.intel.com> (raw)
In-Reply-To: <20140113192245.3F682C7F@viggo.jf.intel.com>
From: Dave Hansen <dave.hansen@linux.intel.com>
This just continues to move things under the Memory and NUMA
Options menu, breaking it up a bit to make the patches easier to
audit.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/arch/x86/Kconfig | 248 ++++++++++++++++++------------------
1 file changed, 124 insertions(+), 124 deletions(-)
diff -puN arch/x86/Kconfig~x86-config-move-highmem arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~x86-config-move-highmem 2014-01-13 11:11:34.925179358 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-13 11:11:34.928179494 -0800
@@ -546,6 +546,130 @@ config X86_SUPPORTS_MEMORY_FAILURE
depends on X86_64 || !SPARSEMEM
select ARCH_SUPPORTS_MEMORY_FAILURE
+choice
+ prompt "High Memory Support"
+ default HIGHMEM64G if X86_NUMAQ
+ default HIGHMEM4G
+ depends on X86_32
+
+config NOHIGHMEM
+ bool "off"
+ depends on !X86_NUMAQ
+ ---help---
+ Linux can use up to 64 Gigabytes of physical memory on x86 systems.
+ However, the address space of 32-bit x86 processors is only 4
+ Gigabytes large. That means that, if you have a large amount of
+ physical memory, not all of it can be "permanently mapped" by the
+ kernel. The physical memory that's not permanently mapped is called
+ "high memory".
+
+ If you are compiling a kernel which will never run on a machine with
+ more than 1 Gigabyte total physical RAM, answer "off" here (default
+ choice and suitable for most users). This will result in a "3GB/1GB"
+ split: 3GB are mapped so that each process sees a 3GB virtual memory
+ space and the remaining part of the 4GB virtual memory space is used
+ by the kernel to permanently map as much physical memory as
+ possible.
+
+ If the machine has between 1 and 4 Gigabytes physical RAM, then
+ answer "4GB" here.
+
+ If more than 4 Gigabytes is used then answer "64GB" here. This
+ selection turns Intel PAE (Physical Address Extension) mode on.
+ PAE implements 3-level paging on IA32 processors. PAE is fully
+ supported by Linux, PAE mode is implemented on all recent Intel
+ processors (Pentium Pro and better). NOTE: If you say "64GB" here,
+ then the kernel will not boot on CPUs that don't support PAE!
+
+ The actual amount of total physical memory will either be
+ auto detected or can be forced by using a kernel command line option
+ such as "mem=256M". (Try "man bootparam" or see the documentation of
+ your boot loader (lilo or loadlin) about how to pass options to the
+ kernel at boot time.)
+
+ If unsure, say "off".
+
+config HIGHMEM4G
+ bool "4GB"
+ depends on !X86_NUMAQ
+ ---help---
+ Select this if you have a 32-bit processor and between 1 and 4
+ gigabytes of physical RAM.
+
+config HIGHMEM64G
+ bool "64GB"
+ depends on !M486
+ select X86_PAE
+ ---help---
+ Select this if you have a 32-bit processor and more than 4
+ gigabytes of physical RAM.
+
+endchoice
+
+choice
+ prompt "Memory split" if EXPERT
+ default VMSPLIT_3G
+ depends on X86_32
+ ---help---
+ Select the desired split between kernel and user memory.
+
+ If the address range available to the kernel is less than the
+ physical memory installed, the remaining memory will be available
+ as "high memory". Accessing high memory is a little more costly
+ than low memory, as it needs to be mapped into the kernel first.
+ Note that increasing the kernel address space limits the range
+ available to user programs, making the address space there
+ tighter. Selecting anything other than the default 3G/1G split
+ will also likely make your kernel incompatible with binary-only
+ kernel modules.
+
+ If you are not absolutely sure what you are doing, leave this
+ option alone!
+
+ config VMSPLIT_3G
+ bool "3G/1G user/kernel split"
+ config VMSPLIT_3G_OPT
+ depends on !X86_PAE
+ bool "3G/1G user/kernel split (for full 1G low memory)"
+ config VMSPLIT_2G
+ bool "2G/2G user/kernel split"
+ config VMSPLIT_2G_OPT
+ depends on !X86_PAE
+ bool "2G/2G user/kernel split (for full 2G low memory)"
+ config VMSPLIT_1G
+ bool "1G/3G user/kernel split"
+endchoice
+
+config PAGE_OFFSET
+ hex
+ default 0xB0000000 if VMSPLIT_3G_OPT
+ default 0x80000000 if VMSPLIT_2G
+ default 0x78000000 if VMSPLIT_2G_OPT
+ default 0x40000000 if VMSPLIT_1G
+ default 0xC0000000
+ depends on X86_32
+
+config HIGHMEM
+ def_bool y
+ depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
+
+config X86_PAE
+ bool "PAE (Physical Address Extension) Support"
+ depends on X86_32 && !HIGHMEM4G
+ ---help---
+ PAE is required for NX support, and furthermore enables
+ larger swapspace support for non-overcommit purposes. It
+ has the cost of more pagetable lookup overhead, and also
+ consumes more pagetable space per process.
+
+config ARCH_PHYS_ADDR_T_64BIT
+ def_bool y
+ depends on X86_64 || X86_PAE
+
+config ARCH_DMA_ADDR_T_64BIT
+ def_bool y
+ depends on X86_64 || HIGHMEM64G
+
endmenu # Memory and NUMA Options
if X86_WANT_INTEL_MID
@@ -1174,130 +1298,6 @@ config X86_CPUID
with major 203 and minors 0 to 31 for /dev/cpu/0/cpuid to
/dev/cpu/31/cpuid.
-choice
- prompt "High Memory Support"
- default HIGHMEM64G if X86_NUMAQ
- default HIGHMEM4G
- depends on X86_32
-
-config NOHIGHMEM
- bool "off"
- depends on !X86_NUMAQ
- ---help---
- Linux can use up to 64 Gigabytes of physical memory on x86 systems.
- However, the address space of 32-bit x86 processors is only 4
- Gigabytes large. That means that, if you have a large amount of
- physical memory, not all of it can be "permanently mapped" by the
- kernel. The physical memory that's not permanently mapped is called
- "high memory".
-
- If you are compiling a kernel which will never run on a machine with
- more than 1 Gigabyte total physical RAM, answer "off" here (default
- choice and suitable for most users). This will result in a "3GB/1GB"
- split: 3GB are mapped so that each process sees a 3GB virtual memory
- space and the remaining part of the 4GB virtual memory space is used
- by the kernel to permanently map as much physical memory as
- possible.
-
- If the machine has between 1 and 4 Gigabytes physical RAM, then
- answer "4GB" here.
-
- If more than 4 Gigabytes is used then answer "64GB" here. This
- selection turns Intel PAE (Physical Address Extension) mode on.
- PAE implements 3-level paging on IA32 processors. PAE is fully
- supported by Linux, PAE mode is implemented on all recent Intel
- processors (Pentium Pro and better). NOTE: If you say "64GB" here,
- then the kernel will not boot on CPUs that don't support PAE!
-
- The actual amount of total physical memory will either be
- auto detected or can be forced by using a kernel command line option
- such as "mem=256M". (Try "man bootparam" or see the documentation of
- your boot loader (lilo or loadlin) about how to pass options to the
- kernel at boot time.)
-
- If unsure, say "off".
-
-config HIGHMEM4G
- bool "4GB"
- depends on !X86_NUMAQ
- ---help---
- Select this if you have a 32-bit processor and between 1 and 4
- gigabytes of physical RAM.
-
-config HIGHMEM64G
- bool "64GB"
- depends on !M486
- select X86_PAE
- ---help---
- Select this if you have a 32-bit processor and more than 4
- gigabytes of physical RAM.
-
-endchoice
-
-choice
- prompt "Memory split" if EXPERT
- default VMSPLIT_3G
- depends on X86_32
- ---help---
- Select the desired split between kernel and user memory.
-
- If the address range available to the kernel is less than the
- physical memory installed, the remaining memory will be available
- as "high memory". Accessing high memory is a little more costly
- than low memory, as it needs to be mapped into the kernel first.
- Note that increasing the kernel address space limits the range
- available to user programs, making the address space there
- tighter. Selecting anything other than the default 3G/1G split
- will also likely make your kernel incompatible with binary-only
- kernel modules.
-
- If you are not absolutely sure what you are doing, leave this
- option alone!
-
- config VMSPLIT_3G
- bool "3G/1G user/kernel split"
- config VMSPLIT_3G_OPT
- depends on !X86_PAE
- bool "3G/1G user/kernel split (for full 1G low memory)"
- config VMSPLIT_2G
- bool "2G/2G user/kernel split"
- config VMSPLIT_2G_OPT
- depends on !X86_PAE
- bool "2G/2G user/kernel split (for full 2G low memory)"
- config VMSPLIT_1G
- bool "1G/3G user/kernel split"
-endchoice
-
-config PAGE_OFFSET
- hex
- default 0xB0000000 if VMSPLIT_3G_OPT
- default 0x80000000 if VMSPLIT_2G
- default 0x78000000 if VMSPLIT_2G_OPT
- default 0x40000000 if VMSPLIT_1G
- default 0xC0000000
- depends on X86_32
-
-config HIGHMEM
- def_bool y
- depends on X86_32 && (HIGHMEM64G || HIGHMEM4G)
-
-config X86_PAE
- bool "PAE (Physical Address Extension) Support"
- depends on X86_32 && !HIGHMEM4G
- ---help---
- PAE is required for NX support, and furthermore enables
- larger swapspace support for non-overcommit purposes. It
- has the cost of more pagetable lookup overhead, and also
- consumes more pagetable space per process.
-
-config ARCH_PHYS_ADDR_T_64BIT
- def_bool y
- depends on X86_64 || X86_PAE
-
-config ARCH_DMA_ADDR_T_64BIT
- def_bool y
- depends on X86_64 || HIGHMEM64G
-
config MATH_EMULATION
bool
prompt "Math emulation" if X86_32
_
next prev parent reply other threads:[~2014-01-13 19:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 19:22 [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Dave Hansen
2014-01-13 19:22 ` [PATCH 01/12] x86 Kconfig: create extended platforms menu Dave Hansen
2014-01-13 19:22 ` [PATCH 02/12] x86 Kconfig: memory options Dave Hansen
2014-01-13 19:22 ` Dave Hansen [this message]
2014-01-13 19:22 ` [PATCH 04/12] x86 Kconfig: processor options menu Dave Hansen
2014-01-13 19:22 ` [PATCH 05/12] x86 Kconfig: processor drivers Dave Hansen
2014-01-13 19:22 ` [PATCH 06/12] x86 Kconfig: scheduler options Dave Hansen
2014-01-13 19:22 ` [PATCH 07/12] x86 Kconfig: move memtest Dave Hansen
2014-01-13 19:22 ` [PATCH 08/12] x86 Kconfig: bury obscure options Dave Hansen
2014-01-13 19:22 ` [PATCH 09/12] x86 Kconfig: create mtrr menu under processsor options Dave Hansen
2014-01-13 19:22 ` [PATCH 10/12] x86 Kconfig: MCE menu Dave Hansen
2014-01-13 19:22 ` [PATCH 11/12] x86 Kconfig: create x86/Kconfig.virt Dave Hansen
2014-01-13 22:46 ` Paolo Bonzini
2014-01-13 23:00 ` Dave Hansen
2014-01-13 23:12 ` Paolo Bonzini
2014-01-14 0:04 ` Dave Hansen
2014-01-13 19:23 ` [PATCH 12/12] x86 Kconfig: move paravirt under "Virtualization" Dave Hansen
2014-01-14 14:25 ` [PATCH 00/12] [v2] Reorganize x86 Kconfig menu Borislav Petkov
2014-01-14 22:12 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2013-12-30 18:40 [PATCH 00/12] " Dave Hansen
2013-12-30 18:40 ` [PATCH 03/12] x86 Kconfig: move highmem Dave Hansen
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=20140113192249.3A34B048@viggo.jf.intel.com \
--to=dave@sr71.net \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@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.