From: rwhron@earthlink.net
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 1-2-3 GB
Date: Sat, 12 Jan 2002 16:41:56 -0500 [thread overview]
Message-ID: <20020112164156.A7069@earthlink.net> (raw)
In-Reply-To: <20020112004528.A159@earthlink.net> <20020112125625.E1482@inspiron.school.suse.de>
In-Reply-To: <20020112125625.E1482@inspiron.school.suse.de>; from andrea@suse.de on Sat, Jan 12, 2002 at 12:56:25PM +0100
Based on some of the comments in the thread, here
is what I came up with for Configure.help.
Also, in the patch, I had 3GB as the default config
option. It may be safer to have 1GB as the default
configure option to match the mainline.
--- linux.aa2/Documentation/Configure.help Fri Jan 11 20:57:58 2002
+++ linux/Documentation/Configure.help Sat Jan 12 16:29:21 2002
@@ -376,6 +376,59 @@
Select this if you have a 32-bit processor and more than 4
gigabytes of physical RAM.
+# Choice: maxvm
+Maximum Virtual Memory
+CONFIG_1GB
+ If you have 4 Gigabytes of physical memory or less, you can change
+ where the where the kernel maps high memory. If you have less
+ than 1 gigabyte of physical memory, you should disable
+ CONFIG_HIGHMEM4G because you don't need the choices below.
+
+ If you have a large amount of physical memory, all of it may not
+ be "permanently mapped" by the kernel. The physical memory that
+ is not permanently mapped is called "high memory".
+
+ The numbers in the configuration options are not precise because
+ of the kernel's vmalloc() area, and the PCI space on motherboards
+ may vary as well. Typically there will 128 megabytes less
+ "user memory" mapped than the number in the configuration option.
+ Saying that another way, "high memory" will usually start 128
+ megabytes lower than the configuration option.
+
+ Selecting "05GB" results in a "3.5GB/0.5GB" kernel/user split:
+ 3.5 gigabytes are kernel mapped so each process sees a 3.5
+ gigabyte virtual memory space and the remaining part of the 4
+ gigabyte virtual memory space is used by the kernel to permanently
+ map as much physical memory as possible. On a system with 1 gigabyte
+ of physical memory, you may get 384 megabytes of "user memory" and
+ 640 megabytes of "high memory" with this selection.
+
+ Selecting "1GB" results in a "3GB/1GB" kernel/user split:
+ 3 gigabytes are mapped so each process sees a 3 gigabyte virtual
+ memory space and the remaining part of the 4 gigabyte virtual memory
+ space is used by the kernel to permanently map as much physical
+ memory as possible. On a system with 1 gigabyte of memory, you may
+ get 896 MB of "user memory" and 128 megabytes of "high memory"
+
+ Selecting "2GB" results in a "2GB/2GB" kernel/user split:
+ 2 gigabytes are mapped so each process sees a 2 gigabyte virtual
+ memory space and the remaining part of the 4 gigabyte virtual memory
+ space is used by the kernel to permanently map as much physical
+ memory as possible. On a system with 1 to 1.75 gigabytes of
+ physical memory, this option have all make it so no memory is
+ mapped as "high memory".
+
+ Selecting "3GB" results in a "1GB/3GB" kernel/user split:
+ 1 gigabyte is mapped so each process sees a 1 gigabyte virtual
+ memory space and the remaining part of the 4 gigabytes of virtual
+ memory space is used by the kernel to permanently map as much
+ physical memory as possible.
+
+ Options "2GB" and "3GB" may expose bugs that were dormant in
+ certain hardware and possibly even the kernel.
+
+ If unsure, say "1GB".
+
HIGHMEM I/O support
CONFIG_HIGHIO
If you want to be able to do I/O to high memory pages, say Y.
--
Randy Hron
next prev parent reply other threads:[~2002-01-12 21:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-12 5:45 [PATCH] 1-2-3 GB rwhron
2002-01-12 7:32 ` H. Peter Anvin
2002-01-12 13:17 ` Andrea Arcangeli
2002-01-12 17:26 ` Albert D. Cahalan
2002-01-12 17:42 ` Andrea Arcangeli
2002-01-12 18:28 ` Albert D. Cahalan
2002-01-12 19:07 ` BIO Usage Error or Conflicting Designs Andre Hedrick
2002-01-12 20:05 ` Jens Axboe
2002-01-13 1:15 ` Andre Hedrick
2002-01-13 12:59 ` Jens Axboe
2002-01-13 19:59 ` Andre Hedrick
2002-01-14 6:42 ` Jens Axboe
2002-01-12 20:59 ` [PATCH] 1-2-3 GB H. Peter Anvin
2002-01-12 11:56 ` Andrea Arcangeli
2002-01-12 15:50 ` rwhron
2002-01-12 19:22 ` Hugh Dickins
2002-01-12 21:02 ` Andrew Morton
2002-01-13 20:24 ` H. Peter Anvin
2002-01-13 23:11 ` Marvin Justice
2002-01-14 0:03 ` H. Peter Anvin
2002-01-14 0:46 ` Alan Cox
2002-01-14 2:21 ` Rik van Riel
2002-01-18 21:18 ` Pavel Machek
2002-01-19 0:24 ` Hugh Dickins
2002-01-12 21:41 ` rwhron [this message]
2002-01-12 22:34 ` rwhron
-- strict thread matches above, loose matches on Subject: below --
2002-01-15 14:07 rwhron
2002-01-15 17:48 ` Dave Jones
2002-01-16 2:12 ` H. Peter Anvin
2002-01-23 3:53 ` rwhron
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=20020112164156.A7069@earthlink.net \
--to=rwhron@earthlink.net \
--cc=andrea@suse.de \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox