From: Bill Davidsen <davidsen@tmr.com>
To: Jurriaan <thunder7@xs4all.nl>,
Linux Kernel mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options
Date: Fri, 15 Dec 2006 12:06:12 -0500 [thread overview]
Message-ID: <4582D604.5000403@tmr.com> (raw)
In-Reply-To: <20061214152721.GA5652@amd64.of.nowhere>
thunder7@xs4all.nl wrote:
> From: Theodore Tso <tytso@mit.edu>
> Date: Thu, Dec 14, 2006 at 10:17:45AM -0500
>> Remove an (incorrect) assertion that NOHIGHMEM is right for more
>> users, since most systems are coming with at least 1G of memory these
>> days, and even some laptops have up 4G of memory.
>
> Given this (on a system with 1G of memory, this option shouldn't be
> used)
>
>> 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.
>> + more than 1 Gigabyte total physical RAM, answer "off" here.
>
> wouldn't
>
> + 1 Gigabyte or more total physical RAM, answer "off" here.
>
> make clearer that even with 1G memory, you shouldn't use this option?
> Since 1G is quite common, we should, IMHO, be clear about that case.
Actually, if you want it to be perfectly clear to people who don't keep
x86 spec sheets in the bathroom for spare time study, a redundant config
option for NX would be required. Then the logic would be:
PAE = MEM>4G || NX
as far as the actual build was concerned. Or you could reject NX in
config unless PAE was selected.
I don't think you will avoid confusion when you have two unrelated
reasons for enabling the same feature.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2006-12-15 17:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-14 9:26 Executability of the stack Franck Pommereau
2006-12-14 9:57 ` Arjan van de Ven
2006-12-14 12:07 ` Franck Pommereau
2006-12-14 12:19 ` Arjan van de Ven
2006-12-14 15:17 ` [PATCH] Clarify i386/Kconfig explanation of the HIGHMEM config options Theodore Tso
2006-12-14 15:27 ` thunder7
2006-12-14 15:37 ` Theodore Tso
2006-12-14 16:06 ` Arjan van de Ven
2006-12-14 16:11 ` Avi Kivity
2006-12-14 19:58 ` Alistair John Strachan
2006-12-15 17:06 ` Bill Davidsen [this message]
2006-12-14 15:52 ` Arjan van de Ven
2006-12-14 12:36 ` Executability of the stack James Courtier-Dutton
[not found] ` <1166099950.27217.1024.camel@laptopd505.fenrus.org>
2006-12-14 14:55 ` Franck Pommereau
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=4582D604.5000403@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thunder7@xs4all.nl \
/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