I have to agree with Eric, that from an architectural perspective,
PAT was invented to address the coarse granularity of the MTRRs
in assigning memory cacheability types.
The power-of-2 sizes and alignments for MTRRs
make them clumsy for page-based
or region-based assignment.
Running out of MTRRs was a real porblem before PAT. MTRRS are best used
to set the "default" for all of memory and then use PAT
to override it on a page-by-page basis as needed.
Using MTRRdef for the actual Aperture is generally ok, because
it is mapped above the top-of-DRAM.
-Rich ...
[richard.brunner@amd.com -- ]
[Senior Member, Technical Staff, SW R&D @ AMD]
> -----Original Message-----
> From: ebiederm@xmission.com [mailto:ebiederm@xmission.com]
> Sent: Sunday, June 16, 2002 9:06 PM
> To: Andi Kleen
> Cc: Andrea Arcangeli; Benjamin LaHaise; linux-kernel@vger.kernel.org;
> Brunner, Richard; Langsdorf, Mark
> Subject: Re: another new version of pageattr caching conflict fix for
> 2.4
>
>
> 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
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:14 EST