lkml.org 
[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:2.517 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site