linux-kernel - Re: HIGHMEM64G Kernel (2.6.23.1) makes system crawl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20071024203726.GA4000@csclub.uwaterloo.ca>
Date:	Wed, 24 Oct 2007 16:37:26 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Boaz Harrosh <bharrosh@...asas.com>
Cc:	Rajkumar S <rajkumars@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: HIGHMEM64G Kernel (2.6.23.1) makes system crawl

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/