Re: MTRR patches ??

Richard Gooch (rgooch@atnf.CSIRO.AU)
Tue, 27 Jan 1998 12:31:34 +1100

Linus Torvalds writes:
> On Tue, 27 Jan 1998, Richard Gooch wrote:
> >
> > 'Cmon, Linus: the XFree86 people might have support for it before the
> > kernel has it ;-/
> My main concern is two-fold:
> - I really think it should be in the arch/i386/ directory regardless of
> any other issues.. (and it should probably show up under a similarly
> machine-dependent name in the /proc filesystem: "/proc/sys/i386/mtrr"
> or similar).

OK, that one I am happy with.

> - does it really make sense to make a device out of it? Might it not be
> equally useful as just a "mtrr" user program that just happens to
> invoce a kernel module (that unloads immediately after having done its
> foul deed).

Doing it that way (i.e. what proform does) is less useful. It's also
slower because the X server would have to fork/exec insmod to load the
module, instead of a simple ioctl(2). Ideally, the X server would
destroy it's region(s) when its VC is switched out, and would create
them again when its VC is switched back. Loading modules every time
would be performance pig.

As for why a /proc interface is more useful:

- it maintains state for multiple regions, so you can:

- support multiple programmes (X server, svgalib) and kernel code
(KGI) creating regions and "destroying" them when no longer needed: a
usage count keeps track of things

- it provides the user/sysadmin with a simple ASCII interface showing
what the current setup is

- being able to destroy regions may be important for some programmes
which don't work properly with write-combining. The ability to
disable/re-enable write-combining quickly may be needed when certain
operations don't work with write-combining, but others (most)
operations work fine and benefit from write-combining.

With multiple heads and multiple programmes accessing the display and
fiddling MTRRs, a /proc interface with state is more robust. Also, I
found that the proform approach was rather clunky.

So, IMO a /proc interface is more robust and more efficient.