Re: [Gems-users] Help with understanding the opal_stats output

[Luke Yen <lyen@xxxxxxxxxxx>]

Hi Brian,

   Here's a detailed explanation of what you might be interested in:

   Opal keeps track of branch predictor statistics in the .opal output
file, and they are summarized in the section entitled "Branch stats".
Grep for "TOTALB" and you will see a summary of total predictions, total
correct, total mispredicted.  It is easy to calculate the total rollback
penalty: BRANCHPRED_MISPRED_PENALTY * (total number of mispredictions),
but it does not calculate the other penalty of re-execution down the
correct path.

  Front-end stalls are captured by the section entitled "Reasons for fetch
stalls", and are broken down by categories such as I-cache miss, I-TLB
miss, instruction window being full, fetch barriers.  Resource unit
stalls can be seen in the section entitled "Execution unit statistics".

  Data dependency stalls are not captured directly in the stats file. If
you are looking for detailed opcode pipeline stalls,
I myself have modified Opal to print out detailed pipeline stall
time stats for each opcode type (similar to the per-opcode stats already
in place). It is pretty easy to do this, and this is accomplished by adding
additional event types to the "inst_time_t" struct declared in
opal/system/dynamic.h, and then setting those fields at appropriate
pipeline stages (such as when operands are ready and when execution
completes). See dynamic.C and memop.C for examples on setting these
timestamps. Then those timestamps can be analyzed by opal/system/sysstat.C's
observeInstruction(), which is called when the Opal sequencer retires an
instruction.
    Data dependency stalls can be analogously added by keeping
track of additional events (see inst_event_t events in dynamic.h, and the
setEvent() and getEvent() functions in dynamic.C and memop.C) as well as
register dependencies. Register dependencies are easily obtained during
the scheduling stage (see dynamic_inst_t::Schedule()), and instruction are
put on wait lists if there are any dependencies.

   Luke

On Thu, 16 Mar
2006, Brian Hing-Kit Tsang wrote:

> Hi,
>
> I was wondering if anyone could help me decipher the opal_stats output.
>
> I believe I understand most of the output, but had a few questions.  I am
> using the MOESI_CMP_directory protocol on an UltraSparcII target machine.
>
> I want to try to figure out where the majority of the stall are in the
> benchmark I ran.  Is there anyway to find the total number of stalls and
> the breakdown of what % of those stalls are branch mispredictions, data
> dependencies, etc... I basically want a way to determine the bottlenecks
> of the system.
>
> Thanks,
> Brian tsang
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>