Messages in this thread | | | Date | Wed, 5 Aug 1998 14:38:05 +1000 | From | Richard Gooch <> | Subject | Re: FB and MTRR |
| |
David Wragg writes: > Richard Gooch <Richard.Gooch@atnf.csiro.au> writes: > > > <rant> > > > I see that the PAT feature of the Xeon puts MTRR attributes in the page > > > table entries, which is a far neater solution than this variable/fixed > > > range stuff. As I understand it, the PPro caches MTRR attributes in > > > the TLB anyway, so why did Intel come up with this fiddly ranges > > > scheme in the first place? Ditto with regard to PAE/PSE36. > > > </rant> > > > > Does the Xeon take away the MTRR registers? > > No, they're still there. PAT is always enabled in the Xeon, but with > the default settings, and all of the previously reserved bits in the > page table entries set to 0, the MTRR ranges will work just as in the > PPro/PII. (Or so the Xeon spec addendum I got from Intel's web site > says). > > > About having MTRR attributes in the page tables: does that mean that > > each process accessing the FB needs it's own page tables to keep this > > information? > > It says that the cache-flushing business that MTRR changes require is > still needed for PAT memory type changes, but doesn't go into > details. Given this, I can't see any advantage of doing fancy > per-process attributes (you could have a physical page mapped into one > process at one location, and into another at another location, as long > as they have the same PAT memory types, I suppose). > > > What kinds of overheads are we looking at for this extra > > maintenance? > > The advantage of the PAT scheme (and the reason Linux might want it > one day) is that there is no arbitrary limit on how many "ranges" you > can have. > > A lot would depend on how it was implemented. Since I can't see people > crying out for this to be supported in the near future, I haven't > given it much thought. > > > The existing PPro/PII MTRR interface controls regions of bus > > addresses, which is common to all processes. This is the way it should > > be, IMHO. Fiddling the page tables of each process that wants to > > access the FB is a PITA. > > Yes, it definitely puts the emphasis on doing the management in > software. > > For devices you don't need an "infinite" number of ranges, so if that > was the motivation I don't see why Intel didn't just bump the number > of ranges up (unless that is hard for implementation reasons). The > memory types can also be used to get closer to achieving the maximum > theoretical memory bandwidth of the processor, in applications where > that is a concern; maybe that is part of the motivation.
OK, so this seems to confirm my view: leave things as they are. If one day we either:
- have a real application that needs more MTRRs - Intel takes away MTRRs forcing us to fiddle the page tables
we can add per-page MTRR support, preserving the existing interface (i.e. conceptually still provide control over N physical regions in a global fashion).
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |