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:	Thu, 7 May 2009 16:16:42 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@....cz>
Cc:	Rik van Riel <riel@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org, mingo@...hat.com, akpm@...ux-foundation.org
Subject: Re: [PATCH] x86: 46 bit PAE support


* Pavel Machek <pavel@....cz> wrote:

> On Wed 2009-05-06 08:20:59, Rik van Riel wrote:
> > H. Peter Anvin wrote:
> >> Rik van Riel wrote:
> >>> Testing: booted it on an x86-64 system with 6GB RAM.  Did you really think
> >>> I had access to a system with 64TB of RAM? :)
> >>
> >> No, but it would be good if we could test it under Qemu or KVM with an
> >> appropriately set up sparse memory map.
> >
> > I don't have a system with 1TB either, which is how much space
> > the memmap[] would take...
> 
> Do we really have 1 byte overhead per 64 bytes of RAM?
> 								Pavel

Yes, struct page is ~64 bytes, and 64*64 == 4096.

Alas, it's not a problem: my suggestion wasnt to simulate 64 TB of 
RAM. My suggestion was to create a sparse physical memory map (in a 
virtual machine) that spreads ~1GB of RAM all around the 64 TB 
physical address space. That will test whether the kernel is able to 
map and work with such physical addresses. (which will cover most of 
the issues)

A good look at /debug/x86/dump_pagetables with such a system booted 
up would be nice as well - to make sure every virtual memory range 
is in its proper area, and that there's enough free space around 
them.

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