All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Jan Beulich" <jbeulich@novell.com>
Cc: "Andreas Herrmann" <andreas.herrmann3@amd.com>,
	"Suresh B Siddha" <suresh.b.siddha@intel.com>,
	"Richard Gooch" <rgooch@safe-mbox.com>,
	linux-kernel@vger.kernel.org, discuss@x86-64.org
Subject: Re: [discuss] [patch] mtrr: fix issues with large addresses
Date: Tue, 6 Feb 2007 11:54:57 +0100	[thread overview]
Message-ID: <200702061154.57621.ak@suse.de> (raw)
In-Reply-To: <45C85E41.76E4.0078.0@novell.com>

On Tuesday 06 February 2007 10:53, Jan Beulich wrote:
> >> I don't think I remember a restriction here, at least not below 44 bits
> >> (that's where pfn-s would need to become 64-bit wide).
> >
> >The i386 mm code only supports 4 entries in the PGD, so more than 36bit cannot 
> >be mapped right now.
> 
> That has nothing to do with the number of physical address bits.

You couldn't use the memory in any ways.

Anyways I give up -- the check is probably not needed, unless Andreas
comes up with a good reason.

> 
> >Also even 64MB barely works (many boxes don't boot), you would likely
> >need at least the 4:4 patch to go >64GB. Also we know there are tons
> >of possible deadlocks in various subsystems when the lowmem:highmem ratio 
> >gets so out of hand.
> >
> >Ok it could be probably all fixed with some work (at least the mm part,
> >the deadlocks would be more tricky), but would seem fairly 
> >pointless to me because all machines with >36bits support are 64bit capable.
> 
> That's a different story, and certainly a limiting factor. But this shouldn't
> e.g. disallow (hypothetical?) systems that have a very sparse memory map
> extending beyond 64G.

They would need a discontig kernel to boot most likely, otherwise
mem_map would fill up their memory. 

And I was told Windows doesn't like that, so it's unlikely there will ever be such
x86 machines.

-Andi

  reply	other threads:[~2007-02-06 10:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-05 17:19 [patch] mtrr: fix issues with large addresses Andreas Herrmann
2007-02-05 22:50 ` Siddha, Suresh B
2007-02-06  7:53   ` Andi Kleen
2007-02-06  9:31     ` [discuss] " Jan Beulich
2007-02-06  9:45       ` Andi Kleen
2007-02-06  9:53         ` Jan Beulich
2007-02-06 10:54           ` Andi Kleen [this message]
2007-02-06 16:25             ` Andreas Herrmann
2007-02-06 16:16       ` Andreas Herrmann
2007-02-06  0:26 ` Eric W. Biederman
2007-02-06 16:08   ` Andreas Herrmann
2007-02-06 17:54     ` Eric W. Biederman
2007-02-06 18:42       ` [discuss] " Andreas Herrmann
2007-02-06 19:08         ` Eric W. Biederman
2007-02-06 19:25           ` Joerg Roedel
2007-02-06 19:44             ` Eric W. Biederman

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=200702061154.57621.ak@suse.de \
    --to=ak@suse.de \
    --cc=andreas.herrmann3@amd.com \
    --cc=discuss@x86-64.org \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@safe-mbox.com \
    --cc=suresh.b.siddha@intel.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.