eap@bu-cs.BU.EDU (Eric A. Pearce) (06/15/89)
Is there a way to get a load average on the Iris? The BSD way would be to nlist the kernel and find "_avenrun", but I did not see anything similar on the Iris. What I am after is an "/usr/ucb/uptime" clone, i.e. 7:41pm up 14 days, 1:48, 7 users, load average: 1.05, 0.90, 0.61 It looks like everthing other than the load average can be obtained from /etc/utmp. (as a side effort, it would be nice to get "loadst" to work in GNU emacs) This is on 4D GTX running IRIX 3.1G. Thanks -e -- ------------------------------------------------------------------------------- Eric Pearce eap@bu-it.bu.edu Boston University Information Technology 111 Cummington Street Boston MA 02215 617-353-2780 voice 617-353-6260 fax
rayan@ai.toronto.edu (Rayan Zachariassen) (06/21/89)
In article <33027@bu-cs.BU.EDU> eap@bu-it.bu.edu (Eric A. Pearce) writes: # Is there a way to get a load average on the Iris? The BSD way # would be to nlist the kernel and find "_avenrun", but I did not see # anything similar on the Iris. There are a couple of system calls that return all kinds of poorly documented kernel stats. Unfortunately I don't see anything that returns the load average directly. Here is the closest I've come while fiddling around with this (I wish this was in the kernel...): #include <stdio.h> #include <sys/types.h> #include <sys/sysmp.h> #include <sys/sysinfo.h> #define INTERVAL 5 #define NSAMPLES (15 /* minutes */ * 60 /* sec/min */ / INTERVAL) int ringload[NSAMPLES]; int ringindex = 0; main() { struct sysinfo sinfo; int flag = 0, now, last1, last5, last15; setvbuf(stdout, (char *)NULL, _IOLBF, 0); for (;;) { now = ringindex; sysmp(MP_SAGET, MPSA_SINFO, &sinfo, sizeof sinfo); ringload[ringindex++] = sinfo.runque; if (!flag) { while (flag < NSAMPLES) ringload[flag++] = sinfo.runque; if (!flag) break; /* shut up the compiler */ } ringindex %= NSAMPLES; last1 = (NSAMPLES + now - 60 / INTERVAL)%NSAMPLES; last5 = (NSAMPLES + now - 5*60 / INTERVAL)%NSAMPLES; last15 = ringindex; printf("%6.2f %6.2f %6.2f\n", (ringload[now] - ringload[last1])/60.0, (ringload[now] - ringload[last5])/(5*60.0), (ringload[now] - ringload[last15])/(15*60.0)); sleep(INTERVAL); } /* NOTREACHED */ exit(0); }
jmb@patton.sgi.com (Jim Barton) (06/21/89)
The typical BSD load average available by reading the avenrun[] variable
out of the kernel will be available with the next software release (3.2).
We keep slogging through the mud, and eventually we'll get everybody's
little hook - it just takes time.
And, although Rayan is correct that all the info hooks into the kernel
are poorly documented, I would argue that they are just as well documented
as they are in BSD or System V kernels - maybe better. But these things
are poorly documented because they change from release to release as the
kernel changes - thus documenting the interface can force you to
support obsolete ways of doing things. Things that get kernel performance
data and read kernel data space are, by definition, "non portable" and
not gauranteed to work release-to-release.
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb
--jmb@patton.sgi.com (Jim Barton) (06/23/89)
As a followup to my last message, I checked the actual code and the avenrun[]
variable is actually kept as an array of longs, not doubles as in BSD4.3.
The longs are kept as "fixed point" values with three decimal points of
precision.
We have a rule at SGI - NO FLOATING POINT IN THE KERNEL. Doing floating
point in the kernel causes more problems that it solves. For instance,
if the kernel did floating point, then the FP registers would have to
be saved and restored on every trip in and out of the kernel - gag! On
every interrupt too - double gag!
So while you'll be able to get the same load average answer (I have a
program which does it today), BSD code which depends on avenrun being
a double will break. This is an incompatibility I don't mind at all.
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb
--