linux-kernel - Re: HIMEM calculation

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]

Date:	Mon, 03 Sep 2007 19:40:58 -0400
From:	Chris Snook <csnook@...hat.com>
To:	"James C. Georgas" <jgeorgas@...rgas.ca>
CC:	linux-kernel@...r.kernel.org
Subject: Re: HIMEM calculation

James C. Georgas wrote:
> I'm not sure I understand how the kernel calculates the amount of
> physical RAM it can map during the boot process.
> 
> I've quoted two blocks of kernel messages below, one for a kernel with
> NOHIGHMEM and another for a kernel with HIGHMEM4G.
> 
> If I do the math on the BIOS provided physical RAM map, there is less
> than 5MiB of the address space reserved. Since I only have 1GiB of
> physical RAM in the board, I figured that it would still be possible to
> physically map 1019MiB, even with the 3GiB/1GiB split between user space
> and kernel space that occurs with NOHIGHMEM.
> 
> However, What actually happens is that I'm 127MiB short of a full GiB.
> 
> What am I missing here? Why does that last 127MiB have to go in HIGHMEM?

That's the vmalloc address space.  You only get 896 MB in the NORMAL 
zone on i386, to leave room for vmalloc.  If you don't like it, go 64-bit.

	-- Chris
-
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/