[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: FB and MTRR
    David Wragg writes:
    > Richard Gooch <> 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).



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:43    [W:0.024 / U:4.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site