public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@muc.de>
Cc: kraxel@suse.de, jsimmons@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use MTRRs by default for vesafb on x86-64
Date: 19 May 2003 06:26:01 -0600	[thread overview]
Message-ID: <m1he7r2kdi.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20030519103717.GC15709@averell>

Andi Kleen <ak@muc.de> writes:

> On Sat, May 17, 2003 at 12:58:39AM +0200, Eric W. Biederman wrote:
> > I don't know if this affects the frame buffers per se.
> > 
> > But often BIOS's on systems with large amounts of memory configure
> > overlapping mtrrs (where an uncacheable mtrr would override a larger
> > cacheable range).  To date this has confused the linux mtrr code when
> > it tries to modify things, and you cannot properly setup mtrrs.    I
> > believe this applies to both the fb case as well as X.
> 
> Interesting. Perhaps it would be really better to use change_page_attr()
> with PAT for this. It would avoid these problems.

At least for x86-64 I would recommend that, as you can count on it existing.

For normal x86 it is more interesting.  But you are less likely to run with 
lots of memory so this case is less likely to show up. I have already heard
people seriously discussing 16GB on an off the shelf on an x86-64
system.  Getting 2GB PC2700 DIMMs is still a bit of a challenge, but
the practical memory size barrier (3GB per task) is finally gone.

For x86-64 a software ``mtrr'' that maps everything the e820 map says
is memory as write-back and everything else as uncacheable by default would
be nice.  As the mtrr interface is already understood by things like X.  And
there needs to be some data structure that remembers what the page
cache-ability attributes should be.

Eric

  reply	other threads:[~2003-05-19 12:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 14:56 [PATCH] Use MTRRs by default for vesafb on x86-64 Andi Kleen
2003-05-15 15:16 ` Dave Jones
2003-05-15 15:20   ` Andi Kleen
2003-05-15 15:25     ` Dave Jones
2003-05-16 20:51   ` Alan Cox
2003-05-18  5:39     ` Andi Kleen
2003-05-18 16:11       ` Jamie Lokier
2003-05-18 20:40         ` Alan Cox
2003-05-18 22:34           ` Jamie Lokier
2003-05-18 22:52             ` Dave Jones
2003-05-18 23:33               ` Jamie Lokier
2003-05-19  0:02                 ` Dave Jones
2003-05-19  0:28                   ` Jamie Lokier
2003-05-19  1:24                     ` Dave Jones
2003-05-16 22:58 ` Eric W. Biederman
2003-05-19 10:37   ` Andi Kleen
2003-05-19 12:26     ` Eric W. Biederman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-19  9:16 Etienne Lorrain

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=m1he7r2kdi.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=ak@muc.de \
    --cc=jsimmons@infradead.org \
    --cc=kraxel@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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