linux-kernel - Re: Does Linux have plan to support memory hole remapping?

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]

Message-ID: <20080409133414.GA2160@csclub.uwaterloo.ca>
Date:	Wed, 9 Apr 2008 09:34:14 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Arne Georg Gleditsch <arne.gleditsch@...phinics.no>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Zhao Forrest <forrest.zhao@...il.com>, discuss@...-64.org,
	linux-kernel@...r.kernel.org, yhlu.kernel@...il.com, mingo@...e.hu,
	ak@...e.de
Subject: Re: Does Linux have plan to support memory hole remapping?

On Wed, Apr 09, 2008 at 11:50:00AM +0200, Arne Georg Gleditsch wrote:
> Hm, wouldn't the given e820 map and mtrr listing indicate that 512M were
> actually remapped to 32G+ in this case?

The mtrr does list the 512MB as being remapped.  It sais there was 32GB
starting at 0, and 512MB starting at 32GB, and then that there was an
uncacheable 512MB hole at 3.5GB.  So the mtrr does say everything looks
right.

The e820 map also shows it:
BIOS-e820: 0000000000000000 - 0000000000098c00 (usable)
       625,664 bytes
BIOS-e820: 0000000000100000 - 00000000dffa0000 (usable)
 3,756,654,592 bytes
BIOS-e820: 0000000100000000 - 0000000820000000 (usable)
30,601,641,984 bytes

Total of 34,358,922,240 bytes or 32767.221 MiB.  Seems rather close to
the full 32768 MiB in the system.  So looks to me like the mtrr and e820
covers all the ram.  Maybe the kernel looses some of it somewhere for
other purposes.

Isn't there usually a line in dmesg similar to this:
Memory: 1023120k/1048256k available (1927k kernel code, 24748k reserved, 868k data, 176k init)

Maybe it can show how much the kernel reserved for itself in this case.

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