Re: FB and MTRR

[David Wragg]

Richard Gooch <[e-mail]> 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.

--
Dave Wragg