mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Rajkumar S <rajkumars@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: HIGHMEM64G Kernel (2.6.23.1) makes system crawl
Date: Wed, 24 Oct 2007 16:37:26 -0400	[thread overview]
Message-ID: <20071024203726.GA4000@csclub.uwaterloo.ca> (raw)
In-Reply-To: <471F873C.6010002@panasas.com>

On Wed, Oct 24, 2007 at 07:56:12PM +0200, Boaz Harrosh wrote:
> So one thing I don't understand is the difference between CONFIG_HIGHMEM4G
> and regular 32-bit. I always thought that 32 bit means 4GB address space
> and that the HIGHMEM4G is using your above trick but with 32-bit dma_addr_t
> since there is only actual 4GB of real memory and the rest is mapping tricks.
> But I guess I was wrong.

For efficiency reasons the kernel only supports about 900MB of ram on
i386, unless you enable the support for a full 4GB address space which
is what CONFIG_HIGHMEM4G does.  What exactly changes in the memory
management and mapping I am not sure of, but it made some difference.
It only gives 4GB of address space and does not enable PAE, which means
if the system has more ram than it can map in the first 4GB of address
space, then the remaining ram is simply invisible to the system.  So you
might have 4GB ram, and only see 3GB or 2.5GB of it with a 4GB kernel.
If you want the kernel to have access to the rest of the ram then you
need a kernel capable of addressing physical ram at addresses higher
than 4GB, which means either PAE (CONFIG_HIGHMEM64G) or a 64bit kernel.
I believe the comments for the CONFIG_HIGHMEM* options was recently
updated to me correct rather than the rather misleading messages they
have had for years.  Unfortunately it would appear those nice updates
have not gone tp Linus' tree so we are still stuck with the old awful
descriptions.  I wonder what happened to them.

> The other point I was making is why use 36 bit trickery when you have a machine
> that is capable of the full 64-bit, and runs much faster at that? Just a waste of
> a good machine, wont you say? Perhaps we learn to use x86_64 ARCHs before Intel
> fixes their BIOS, and they where right all along?

Because the 36bit trickery works with an i386 system and kernel.  Not
everyone wants to run 64bit and deal with the (few) programs that don't
yet work on 64bit systems.

Personally I run a 64bit kernel with a 32bit user space on any 64bit
capable machines I deal with.  That seems to work fine, and it lets me
play with 64bit programs in a 64bit chroot when I want to.

--
Len Sorensen

  reply	other threads:[~2007-10-24 20:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-24 10:26 Rajkumar S
2007-10-24 14:41 ` Boaz Harrosh
2007-10-24 16:35   ` Lennart Sorensen
2007-10-24 17:56     ` Boaz Harrosh
2007-10-24 20:37       ` Lennart Sorensen [this message]
2007-10-24 17:21   ` H. Peter Anvin
     [not found] <fa.7rN1uBoDAvdkB/ZVQAe63J/uvnk@ifi.uio.no>
2007-10-24 14:26 ` Robert Hancock
2007-10-24 16:16   ` Rajkumar S
     [not found] <fa.wTdv3mFEbQaGOciq1qlqjQYioTk@ifi.uio.no>
     [not found] ` <fa.5twmqnTSoQ6RAav3LKQBxq5jBTw@ifi.uio.no>
     [not found]   ` <fa.USaSUutC3B7gcx/C3bJNmlbDfJk@ifi.uio.no>
2007-10-24 23:18     ` Robert Hancock

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=20071024203726.GA4000@csclub.uwaterloo.ca \
    --to=lsorense@csclub.uwaterloo.ca \
    --cc=bharrosh@panasas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rajkumars@gmail.com \
    /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

all inboxes | Powered by JetHome®