Messages in this thread | | | From | richard.brunner@amd ... | Subject | RE: another new version of pageattr caching conflict fix for 2.4 | Date | Mon, 17 Jun 2002 16:13:11 -0500 |
| |
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/
| |