[comp.sys.pyramid] TOP program on OSx4.1

steve@geops.UUCP (Steve Malone) (09/20/88)

The program, `top' which displays on the user's terminal
a continuously updating list of information about the top 12-18 processes,
does not seem to work under OSx4.1.  It did just fine under 3.5
and was very useful to see what was using machine resources in
a dynamic way.  Anyone with fixes or changes so it will
work on OSx4.1 please let me know.  (The problem seem to be
in the code or structures involving the CPUSTATE).
	Steve Malone
	Geophysics, Univ of Wash.
	Seattle, WA 98195
	(steve @geops.geo.washington.edu)
-- 
Steve Malone                        ARPA:   steve@geops.geo.washington.edu
(206) 545-3811                      UUCP:   uw-beaver!geops!steve
Geophysics Program                  BITNET: MALONES@UWARITA
University of Washington

forys@BOULDER.COLORADO.EDU (Jeff Forys) (09/20/88)

	From:    geops!steve@june.cs.washington.edu  (Steve Malone)
	Subject:  TOP program on OSx4.1

	The `top' program does not seem to work under OSx4.1.
	It did just fine under 3.5 [...] (The problem seem to
	be in the code or structures involving the CPUSTATE).
---
Not exactly.  Pyramids' OSx4.0 release was apparently geared for
multiple processors (where older machines have a multiple of 1).
As a result, they moved `cp_time' [*] into a per-processor struct
(cleverly called `percpu') and changed it's name to `cpu_time'.
The trick then, is finding this thing.

Since we only have single-processor 90x machines here (with no
plans to upgrade), my patch simply grabs the `percpu' struct for
the first (i.e. only) processor.  If you have multiple-CPUs, this
patch will "work", but generate bogus data.  I suppose that, in
the case of multiple-processors, for each state, one might divide
the time spent by each processor by the total number of processors.

Context diff's for `top.c' follow.  After applying them, compile
with `-DPYR4_0' (hmm, should have been PYR=41... too late :-)).

Good luck,
Jeff Forys

[*] The `cp_time' (or Pyramids' `percpu.cpu_time') array keeps track
of how much time a processor spends in each of `CPUSTATES' states.
Usually there are 4 states; user, nice, system, and idle.
-------------------------------- cut here -----------------------------
*** /tmp/,RCSt1017858	Tue Sep 20 02:24:28 1988
--- top.c	Wed Aug 26 20:30:46 1987
***************
*** 38,43 ****
--- 38,46 ----
  #include <sys/proc.h>
  #include <sys/dk.h>
  #include <sys/vm.h>
+ #ifdef PYR4_0
+ #include <sys/systm.h>
+ #endif
  
  /* includes specific to top */
  #include "layout.h"
***************
*** 63,69 ****
--- 66,76 ----
  #define X_AVENRUN	0
      { "_ccpu" },
  #define X_CCPU		1
+ #ifdef PYR4_0
+     { "_percpu" },
+ #else
      { "_cp_time" },
+ #endif
  #define X_CP_TIME	2
      { "_hz" },
  #define X_HZ		3
***************
*** 101,106 ****
--- 108,117 ----
  
  /* All this is to calculate the cpu state percentages */
  
+ #ifdef PYR4_0
+ struct percpu cpus[NCPU];	/* pyramids expect multiple CPUs */
+ #endif
+ 
  long cp_time[CPUSTATES];
  long cp_old[CPUSTATES];
  long cp_change[CPUSTATES];
***************
*** 473,479 ****
--- 484,505 ----
  	getkval(proc, pbase, bytes, "proc array");
  
  	/* get the cp_time array */
+ 
+ #ifdef PYR4_0
+ 	/*
+ 	 * OSx4.0 uses a struct for each CPU.  We have only one,
+ 	 * so the easy thing to do is just use it.  (JEF)
+ 	 */
+ 	{
+ 	    register int i;
+ 
+ 	    getkval(cp_time_offset, cpus, sizeof(cpus), "_percpu");
+ 	    for (i=0; i<CPUSTATES; i++)
+ 		cp_time[i] = cpus[0].cpu_time[i];
+ 	}
+ #else
  	getkval(cp_time_offset, cp_time, sizeof(cp_time), "_cp_time");
+ #endif
  
  	/* get load average array */
  	getkval(avenrun_offset, avenrun, sizeof(avenrun), "_avenrun");