All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Pavel Machek <pavel@ucw.cz>, Rik van Riel <riel@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, mingo@redhat.com, akpm@linux-foundation.org
Subject: Re: [PATCH] x86: 46 bit PAE support
Date: Thu, 7 May 2009 16:49:04 +0200	[thread overview]
Message-ID: <20090507144904.GA2344@elte.hu> (raw)
In-Reply-To: <4A02EFD2.40707@zytor.com>


* H. Peter Anvin <hpa@zytor.com> wrote:

> Ingo Molnar wrote:
> > 
> > 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.
> > 
> 
> We're working on simulating this at Intel.  We should hopefully be 
> able to test this next week.

Wow, very nice!

It would be nice to do it on a KVM basis and submit the 
weird-memory-layout submission to the KVM tree. It would be helpful 
with the reproduction of weird, memory layout dependent bugs too for 
example. Plus we could create a test facility that randomizes the 
physical memory layout (with a given fragmentation level).

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Pavel Machek <pavel@ucw.cz>, Rik van Riel <riel@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, mingo@redhat.com, akpm@linux-foundation.org
Subject: Re: [PATCH] x86: 46 bit PAE support
Date: Thu, 7 May 2009 16:49:04 +0200	[thread overview]
Message-ID: <20090507144904.GA2344@elte.hu> (raw)
In-Reply-To: <4A02EFD2.40707@zytor.com>


* H. Peter Anvin <hpa@zytor.com> wrote:

> Ingo Molnar wrote:
> > 
> > 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.
> > 
> 
> We're working on simulating this at Intel.  We should hopefully be 
> able to test this next week.

Wow, very nice!

It would be nice to do it on a KVM basis and submit the 
weird-memory-layout submission to the KVM tree. It would be helpful 
with the reproduction of weird, memory layout dependent bugs too for 
example. Plus we could create a test facility that randomizes the 
physical memory layout (with a given fragmentation level).

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-05-07 14:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-05 21:28 [PATCH] x86: 46 bit PAE support Rik van Riel
2009-05-05 21:28 ` Rik van Riel
2009-05-06  1:53 ` H. Peter Anvin
2009-05-06  1:53   ` H. Peter Anvin
2009-05-06 12:20   ` Rik van Riel
2009-05-06 12:20     ` Rik van Riel
2009-05-06 12:30     ` Ingo Molnar
2009-05-06 12:30       ` Ingo Molnar
2009-05-07 12:01     ` Pavel Machek
2009-05-07 12:01       ` Pavel Machek
2009-05-07 14:16       ` Ingo Molnar
2009-05-07 14:16         ` Ingo Molnar
2009-05-07 14:27         ` H. Peter Anvin
2009-05-07 14:27           ` H. Peter Anvin
2009-05-07 14:49           ` Ingo Molnar [this message]
2009-05-07 14:49             ` Ingo Molnar
2009-05-06  3:27 ` [tip:x86/mm] x86: 46 bit physical address support on 64 bits tip-bot for Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090507144904.GA2344@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.