Re: MTRR control

Richard Gooch (rgooch@atnf.CSIRO.AU)
Thu, 18 Dec 1997 06:57:17 +1100

yuri mironoff writes:
> Great idea! However I'd like to plead the case of a system call
> interface. (Not necessarily sysctl() - but maybe cachectl(), etc).
> It would be very nice for humans to view MTRR settings through /proc -
> but much easier (not to mention more standard) from a programming
> interface to actually set them through a system call. Please let me
> explain:
> As time has proven again and again - /proc entry display format has
> changed and all the software that depended on that display format became
> instantly broken. There is a finite number of ways you can read/write
> an integer into memory (as a system call argument) - there is an infinite
> number of ways to display the same integer in a human-readable/writable
> format. A properly designed system call would provide the most consistant
> AND efficient interface.

If you look at my patch you'll notice threre are two interfaces: the
ASCII one which is for the system administrator and the ioctl() one
which is meant for programmers. I don't have a problem with changes to
the ASCII interface, since programmes should not rely on it: they
should use the ioctl() interface.
The ASCII read interface is important so the sysadmin can see what's
going on without requiring special tools.

I had originally looked at using sysctl() but it looks like that is
more tuned to setting kernel parameters in memory tables.

> Consider the inefficiency of /proc. I understant that setting MTRR
> registers is done once in a blue moon - however its the principle that
> counts. As it stands right now, far too many utilities/programs rely on
> /proc. Look at "top": 2-8% CPU to display 70 mostly sleeping processes!
> At the risk of repeating myself - an HPUX top manages to fit into 2%
> with 400 processes - worse yet, on a slower CPU. Thats shameful - where
> has the concent of efficiency gone?

I agree that there should be an alternative way of accessing the /proc
information: reading and decoding ASCII is a loose. That's what sysctl
is for, in general.
I believe more /proc entries should provide ioctl() interfaces for the
benefit of C programmes.

I've also made the kernel-side computation of the ASCII information
done when the MTRRs are changed, not every time you read /proc/mtrr. I
can get away with this because the amount of information in there is
trivial. It also has the advantage of allowing me to set the size of
the file, so you can use less and friends. Something no other /proc
entry does, I believe :-)

> As a final argument I'd like to present the possibility that not
> everyone will enable /proc when running Linux.

IMHO /proc is so essential that virtually everybody uses it. It's a
must for sysadmin.

> P.S. Sorry for the long-winded monologue but this is a pet pieve of mine. :)