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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Oct 2007 12:35:20 -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 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
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ