Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: VM Measurement
Message-ID: <12318@pt.cs.cmu.edu>
Date: 11 Mar 91 03:51:49 GMT
Organization: Carnegie Mellon
Lines: 33

Taking my cache-measurement post a bit sideways:

It's difficult to find out the virtual memory behavior of a program.
At one level, that's an OS deficiency, and not the province of this
news group. On the other hand, TLBs are definitely architecture, and
today's designs are deficient in not keeping any measurements. Wasn't
an anecdote posted here, about a mysterious program that turned out
to be thrashing the ETA-10's TLB?

The MIPS chips have a unique advantage here. MIP's TLB refill is done
by software, hence, a user could in theory boot an instrumented
version of the OS.  I suggest collecting, per page, a count of how
many times that page is faulted in to the TLB.

I ran some of this past a Mach-PMAX person, Alessandro Forin, and he
commented, in part:

>-"the" pages that faulted/missed	- easy
>- same, plus how many times		- easy
>- same, plus in what order		- space expensive
>- "the" pages accessed at least once	- easy
>- same, plus in what mode		- easy
>- same, plus how many times		- impossible
>- same, plus in what order		- impossible

Sandro was envisioning logic that that you wouldn't want to see cast
in hardware.  However, it would still be nice if the hardware kept a
measly counter or two.



-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon Robotics