Re: FB and MTRR

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 4 Aug 1998 11:38:51 +1000

David Wragg writes:
> Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:
> > Hi, Geert. IIRC, you wrote a note about using the FB code on i386,
> > and at the end you mentioned using /proc/mtrr to speed up
> > performance. Why not have the FB code call the mtrr_add() function
> > directly? That's what it's there for: for use by kernel graphics
> > drivers.
>
> I was glancing through the FreeBSD kernel source recently, and noticed
> that they use MTRR write-combining over the VGA region (as lomg as
> there is a VGA compatible device detected). Since this is about as far
> as their MTRR support goes, they have a nice simple way of doing this:
> They just hard-code the appropriate values for the fixed range
> registers.
>
> Presumably this works, so it would be nice if Linux did the same. I
> doubt it's worth doing for VGA text-mode alone (though I'm not a heavy
> text-mode user), but it would be good for fbcon and the XFree86
> SVGA-based servers.

Isn't it a bad idea to touch the old VGA registers? I thought it was
better to use the new PCI space registers (so you can support multiple
heads)?

> I can see an easy and a not so easy way to do this:
>
> Not so easy way: Expose the fixed registers through mtrr_add() and
> /proc/mtrr. There are no great problems with this, but we would need
> to keep a list of "virtual" variable ranges for the 0-1MB area and
> translate to the corresponding fixed range settings.
>
> Easy way: Just disable the fixed ranges, so the variable ranges cover
> 0-1MB. Clearly this isn't appropriate if the BIOS does something with
> the fixed ranges other than setting them all to write-back, but I
> suspect that no BIOS tries to be that clever. This would mean we use
> up a variable range for the VGA region, but I doubt anyone is yet down
> to their last one.
>
> I'll have a go at the second option sometime soon.

Sounds sensible.

> <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?
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? What kinds of overheads are we looking at for this extra
maintenance?
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.

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