From: Boaz Harrosh <bharrosh@panasas.com>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
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 19:56:12 +0200 [thread overview]
Message-ID: <471F873C.6010002@panasas.com> (raw)
In-Reply-To: <20071024163520.GM4003@csclub.uwaterloo.ca>
On Wed, Oct 24 2007 at 18:35 +0200, lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> On Wed, Oct 24, 2007 at 04:41:16PM +0200, Boaz Harrosh wrote:
>> I thought that for 4GB of memory the CONFIG_HIGHMEM4G=y CONFIG_HIGHMEM64G is not set
>> would be enough.
>>
>> From looking in source code the CONFIG_HIGHMEM64G is broken in many respects,
>> in my opinion. It's really a 64-bit with 32-bit quirks enabled. Does it even
>> run on None 64-bit machines? Not many!
>>
>> You have a magnificent 64-bit Machine, why?
>
> CONFIG_HIGHMEM4G means 4GB address space. Since PCI and BIOS use some
> of the first 4GB address space, a machine with 4GB of actual RAM must
> map some of that RAM above the 4GB address space, so you access it all
> you need to enable PAE (address space extensions intel invented to give
> 36bit addressing on 32bit machines), which lets the OS map memory above
> 4GB (up to 64GB), to let applications use it. Applications are still
> limited to a 32bit address space. 64bit machines of course just use all
> memory directly without any silly extensions.
>
> The common intel BIOS bug relating to configuring the MTRR and such for
> caching of memory makes the top portion of memory uncached and hence
> very slow, which means any code placed in the top part of memory gets
> slow. The kernel likes to place itself at the top of memory which means
> the kernel gets slow and hence the whole system gets slow. Holefully
> intel will learn to make proper BIOSes real soon so that people with
> intel boards can stop having such slow machines when they have lots of
> ram.
>
> --
> Len Sorensen
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.
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?
Boaz
next prev parent reply other threads:[~2007-10-24 17:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-24 10:26 HIGHMEM64G Kernel (2.6.23.1) makes system crawl Rajkumar S
2007-10-24 14:41 ` Boaz Harrosh
2007-10-24 16:35 ` Lennart Sorensen
2007-10-24 17:56 ` Boaz Harrosh [this message]
2007-10-24 20:37 ` Lennart Sorensen
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=471F873C.6010002@panasas.com \
--to=bharrosh@panasas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--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 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.