public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "Andi Kleen" <andi@firstfloor.org>,
	"Ray Lee" <ray-lk@madrabbit.org>, "Bo Brantén" <bosse@acc.umu.se>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jesse Barnes" <jesse.barnes@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: x86_64 ten times slower than i386
Date: Tue, 06 Nov 2007 11:50:13 -0800	[thread overview]
Message-ID: <4730C575.2020007@zytor.com> (raw)
In-Reply-To: <20071106194009.GC1045@1wt.eu>

Willy Tarreau wrote:
> On Mon, Nov 05, 2007 at 05:19:44PM -0800, H. Peter Anvin wrote:
>> Andi Kleen wrote:
>>>> Jesse Barnes (cc:d) wrote a patch to address this, I think (x86: trim
>>>> memory not covered by WB MTRRs), but as far as I can tell it hasn't
>>>> been merged yet. System is Intel, 4gb of RAM.
>>> It wasn't merged because it broke booting on some systems.
>>> Besides the memory would be still lost -- all it did was to automate
>>> the "mem=XXXX" line.
>> There really are only two ways to deal with this -- drop the memory 
>> (which should be automated, and a warning printed) or adjust the MTRRs. 
>>  The problem is that at some point we run out of MTRRs, partially 
>> because they're masks instead of base/limit.
> 
> Just out of curiosity, what would be the problem if the MTRRs covered more
> than the memory size ? For instance, instead of having 512 MB at 4G, why
> not have 1G at 4G ?

That's fine, *as long as* you don't have any I/O devices there, 
including things like UMA graphics devices or memory areas used by SMM. 
  In theory, those should be marked reserved in e820.  In practice...

That's really the fundamental problem with the Intel MTRR design.  It 
works really well for banks of memory and really poorly as soon as 
something wants to "steal" memory or address space.

	-hpa

  reply	other threads:[~2007-11-06 19:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-03 12:31 x86_64 ten times slower than i386 Bo Brantén
2007-11-03 16:26 ` Matt Mackall
2007-11-03 22:38   ` Bo Brantén
2007-11-03 22:54     ` Matt Mackall
2007-11-03 23:30     ` H. Peter Anvin
2007-11-05  8:06     ` Joseph Fannin
2007-11-05 10:15     ` Bo Brantén
2007-11-05 16:00       ` Bo Brantén
2007-11-05 17:23         ` H. Peter Anvin
2007-11-05 18:46           ` Bo Brantén
2007-11-05 19:11             ` H. Peter Anvin
     [not found]         ` <2c0942db0711050832t5207ea8bib1f75e59e071ade2@mail.gmail.com>
2007-11-06  0:26           ` Andi Kleen
2007-11-06  1:19             ` H. Peter Anvin
2007-11-06 19:40               ` Willy Tarreau
2007-11-06 19:50                 ` H. Peter Anvin [this message]
2007-11-06 19:53                   ` Willy Tarreau
2007-11-07 18:38             ` Jesse Barnes
2007-11-10 13:41         ` Bo Brantén
2007-11-05 17:22       ` H. Peter Anvin

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=4730C575.2020007@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=bosse@acc.umu.se \
    --cc=jesse.barnes@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ray-lk@madrabbit.org \
    --cc=w@1wt.eu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox