Path: utzoo!attcan!uunet!samsung!usc!ucsd!ucbvax!BRL.MIL!mike
From: mike@BRL.MIL (Mike Muuss)
Newsgroups: comp.sys.sgi
Subject: Re:  Processor efficiency
Message-ID: <9006151345.aa05125@WOLF.BRL.MIL>
Date: 15 Jun 90 17:45:14 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 52

In January I also noticed problems with running medium-large programs on the
SGIs, but I have not yet had time to dig in very far;  too much else to do.

In my case, watching a GR-OSVIEW shows a significant (like 25% of
each of the 8 CPUs) "system" loading, 10^5 interrupts/second,
and (as I recall) a large TLBFAULT rate.  My current theory is that
I may be using too many entries in the TLB.

The best description I have seen of this comes from the man page for
GR_OSVIEW, which says:

     tlbfault
             The TLB fault bar gives the number of operating-system handled
             TLB faults initiated by the processor.  There are two kinds of
             faults: double-level faults, and reference faults.

             On the 4D series, translation lookaside buffer (TLB) handling is
             performed entirely by software.  This is done by looking up the
             missing page entry in a page table, and entering the virtual to
             physical mapping into the TLB.  First-level faults are handled by
             extremely efficient low-level software.  The page tables
             themselves are virtually mapped, so when the first level TLB
             handler attempts to load a page table entry, it may fault because
             the page table isn't mapped.  This is a double-level fault, and
             must be repaired by high-level kernel routines.  A reference
             fault occurs when a page is touched, and is used by the operating
             system in keeping accurate usage information for efficient
             paging.

             A high double-level fault rate can be a problem, because of the
             overhead of kernel handling.  Each page table can map 2Mb of
             memory, but each program requires at least three segments: text,
             data and stack.  Additionally, most programs are linked with
             either the shared C library or shared graphics library, each of
             which adds two more segments to the program.  Mapping the
             graphics pipe requires another segment as well.  Gr_osview links
             with these, as well as with the shared font manager library,
             making for a total of 10 segments.  There are 62 TLB entries
             available and gr_osview uses more pages of data than this.  This
             results in a fairly high background double-level fault rate.
             However, the CPU load due to this double-level handling rate is
             not measurable for gr_osview, which is worse in these respects
             than most programs.


This may provide a clue.

By the way, my hat is off to Jim Barton, the author of GR_OSVEW.
A superb monitoring tool!

	Best,
	 -Mike