public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@suse.de>
Cc: Andrea Arcangeli <andrea@suse.de>,
	Benjamin LaHaise <bcrl@redhat.com>,
	linux-kernel@vger.kernel.org,
	Richard Brunner <richard.brunner@amd.com>,
	mark.langsdorf@amd.com
Subject: Re: another new version of pageattr caching conflict fix for 2.4
Date: 16 Jun 2002 22:06:22 -0600	[thread overview]
Message-ID: <m1u1o2tupt.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20020617013732.A14867@wotan.suse.de>

Andi Kleen <ak@suse.de> writes:

> > > MTRRs work on physical, not virtual memory, so they have no aliasing
> > > issues.
> > 
> > Doesn't the AGP aperture cause a physical alias?  Leading to strange
> 
> Yes. That's what this patch is all about.
> 
> > the same problems if the agp aperture was marked write-back, and the
> 
> AGP aperture is uncacheable, not write-back.
> 
> > memory was marked uncacheable.  My gut impression is to just make the
> > agp aperture write-back cacheable, and then we don't have to change
> > the kernel page table at all.  Unfortunately I don't expect the host
> 
> That would violate the AGP specification.
> 
> > bridge with the memory and agp controllers to like that mode,
> > especially as there are physical aliasing issues.
> 
> exactly.

All of which is an AGP design bug, if you want performance you don't
cripple your caches, but we have to live with it so no use tilting at
windmills.

> > > Fixing the MTRRs is fine, but it is really outside the scope of my patch.
> > > Just changing the kernel map wouldn't be enough to fix wrong MTRRs,
> > > because it wouldn't cover highmem. 
> > 
> > My preferred fix is to use PAT, to override the buggy mtrrs.  Which
> > brings up the same aliasing issues.  Which makes it related but
> > outside the scope of the problem.
> 
> I don't follow you here. IMHO it is much easier to fix the MTRRs in the
> MTRR driver for those rare buggy BIOS (if they exist - I've never seen one)

I've heard of several and dealt with one.  The problem was essentially they
ran out of mtrrs, the edges of free memory were to rough.

> than to hack up all of memory management just to get the right bits set.
> I see no disadvantage of using the MTRRs and it is lot simpler than
> PAT and pte bits.

There are not enough MTRRs.  And using the PAT bits to say memory is
write-back can be a constant.  It just takes a little work to get in
place.  Plus the weird assortment of consistency issues.

For most purposes PAT makes memory easier to deal with because you
can be as fine grained as you like.  The difficulty is that you must
have consistent attributes across all of your virtual mappings.  

The other case PAT should help is when a machine has multiple cards
that can benefit from write-combining.  Currently running out of mtrrs
is a problem.

Eric

  parent reply	other threads:[~2002-06-17  4:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-13 20:15 New version of pageattr caching conflict fix for 2.4 Andi Kleen
2002-06-14  1:03 ` Benjamin LaHaise
2002-06-14  1:24   ` Andi Kleen
2002-06-14  1:37     ` Benjamin LaHaise
2002-06-14  4:00       ` Andrea Arcangeli
2002-06-14  4:17         ` Benjamin LaHaise
2002-06-14  4:27           ` Andi Kleen
2002-06-14 15:28             ` Benjamin LaHaise
2002-06-14 16:13               ` Andi Kleen
2002-06-14 17:31                 ` Andrea Arcangeli
2002-06-14 18:05                   ` another new " Andi Kleen
2002-06-16 10:08                     ` Eric W. Biederman
2002-06-16 16:48                       ` Andi Kleen
2002-06-16 17:50                         ` Eric W. Biederman
2002-06-16 18:43                           ` Andi Kleen
2002-06-16 19:56                             ` Eric W. Biederman
2002-06-16 23:37                               ` Andi Kleen
2002-06-17  0:08                                 ` Albert D. Cahalan
2002-06-17  4:06                                 ` Eric W. Biederman [this message]
2002-06-17  6:53                               ` Andrea Arcangeli
2002-06-17 15:46                                 ` Eric W. Biederman
2002-06-14  4:28           ` New " Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2002-06-17 21:07 another new " richard.brunner
2002-06-18 17:34 ` Eric W. Biederman
2002-06-17 21:13 richard.brunner

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=m1u1o2tupt.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=andrea@suse.de \
    --cc=bcrl@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.langsdorf@amd.com \
    --cc=richard.brunner@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox