Generally we want instrumentation to determine the dynamic state of the system.
Here are some suggestions:

Add instrumentation counters:
  - TLB misses       (aggregate and per thread/process?)
  - context switches (aggregate and per thread)
  - floating pt saves(aggregate and per thread)
  - event dispatches (aggregate, per event is already there)
  - mutex locks      (aggregate and per mutex, contention vs success)
  - semaphore        like mutex.
  - interrupts       (aggregate and per Deos defined interrupt)

More event logs:
  when a thread is restarted.
  wait event, pulse event
  lock and unlock mutex
  signal and wait semaphore
The returns from waits or locks can be inferred.

A more through look at the API is in order to see if there are more needed.  The
above are generally useful, and likely won't affect performance significantly
(although TLB would have to be done carefully).

from email:

> -----Original Message-----
> From: Larson, Aaron (MN65) 
> 
> Yea, that's the objective.  You know that all the TLB misses 
> (sans interrupts) between context switches belong to the 
> current thread, so you could sweep the delta into a thread 
> specific counter at ctx times for a minimal cost.  You could 
> even zero the value at ctx time to make it easier.
> 
> I wouldn't be averse to making this sort of code be #ifdef'd 
> if it got expensive, but having some sort of dynamic behavior 
> monitor is critical for tuning, and we don't provide it.
> 
> -----Original Message-----
> From: Roffelsen, Ryan (AZ75) 
> Sent: Wednesday, November 17, 2004 4:40 PM
> To: Larson, Aaron (MN65); Diethelm, Matthew
> Cc: Johnson, G Craig; Cronk, Bill (AZ15)
> Subject: RE: Cost of TLB Miss
> 
> 
> I'm just not sure what value the total number of TLB misses 
> has.  I would think if you could find out the total number of 
> TLB misses on a per process bases it might be more useful. I 
> started to think about this then my head started hurting so I stopped.
> 
> -Ryan 
> 
> > -----Original Message-----
> > From: Larson, Aaron (MN65) 
> > Sent: Wednesday, November 17, 2004 3:36 PM
> > To: Roffelsen, Ryan (AZ75); Diethelm, Matthew
> > Cc: Johnson, G Craig; Cronk, Bill (AZ15)
> > Subject: RE: Cost of TLB Miss
> > 
> > 
> > Note change of recipients.
> > 
> > I was thinking we could increment a 32 bit number stored in 
> > the code immediately following the rfi.  It would (of 
> > necessity) be a cache hit so the extra 3 instructions would 
> > probably cost almost nothing.  I think the 750 has 
> > performance counters for this sort of thing, but I haven't looked.
> > 
> > -----Original Message-----
> > From: Roffelsen, Ryan (AZ75) 
> > Sent: Wednesday, November 17, 2004 4:31 PM
> > To: Diethelm, Matthew; McElroy, James J
> > Cc: Gremmert, Scott; Larson, Aaron (MN65); Johnson, G Craig; 
> > Cronk, Bill (AZ15)
> > Subject: RE: Cost of TLB Miss
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Diethelm, Matthew 
> > > Sent: Wednesday, November 17, 2004 1:39 PM
> > > To: McElroy, James J
> > > Cc: Gremmert, Scott; Larson, Aaron (MN65); Roffelsen, Ryan (AZ75);
> > > Johnson, G Craig; Cronk, Bill (AZ15)
> > > Subject: RE: Cost of TLB Miss
> > > 
> > ...
> > > 
> > > MD: Awesomely good question.  Alas, I'm not equipped mentally 
> > > to answer. :-)  I'm including our other two kernel 
> > > maintainers, Ryan and Aaron, in this conversation as I 
> > > believe they've recently been dealing with TLBs and cache 
> > > lines as part of the upcoming Agave kernel certification.  
> > > One of them can likely yield some information here.
> > 
> > We have no mechanism for measuring TLB miss times.  I'm 
> > guessing any thing we put it to try and measure the TLB miss 
> > time would probably double the time it take to handle a TLB 
> > miss.  What I can do is give you information about the code 
> > so you can estimate it's execution time.
> > The current version of the TLB miss handlers (there are 3, 
> > data write miss, data read miss, code read miss) have:
> > 17 instructions each (two possible cache misses to execute 
> > the code, probably not likely)
> > access two different RAM pages to read (two more possible 
> > cache misses, these are likely)
> > A couple of branches that won't be taken unless it is a real 
> > exception.
> > 
> > Here is the source of one of the TLB miss handlers:
> >     mfsr    r2, sr0
> >     mfspr   r3, dmiss
> >     rlwinm  r2, r2, 8, 0, 19
> >     mfcr    r1
> >     rlwimi  r2, r3, 32-20, 20, 29
> >     lwz     r2, 0(r2)
> >     andi.   r0, r2, PTElo_Pbit
> >     beq     synthesizeDSIonStore
> >     rlwinm  r2, r2,     0,  0, 19
> >     rlwimi  r2, r3, 32-10, 20, 29
> >     lwz     r2, 0(r2)
> >     andi.   r0, r2, PTElo_Pbit
> >     beq     synthesizeDSIonStore
> >     mtspr   rpa, r2
> >     tlbld   r3
> >     mtcr    r1
> >     rfi
> > 
> > 
> > > 
> > > MD: I'm worried that such a statistic couldn't be retrieved 
> > > without a specially instrumented kernel and or PAL.  I'll 
> > > once again leave it up to Ryan or Aaron to confirm or deny.
> > >
> > 
> > As you can see by the code above we do not have any way to 
> > count the number of TLB misses. 
> > 
>


TRACK Comments:

03/10/2005 12:12:28 - mattd - SAS classification Enhancement
11/17/2004 16:12:54 - mattd - No current customer funding stalls progress on
this feature


PCR moved from Track to bugzilla by Aaron.Larson@Honeywell.com 2005-09-22 17:05