Re: [Gems-users] Relation between SIMICS cycle & GEMS cycle

["Weihang Jiang" <weihang.jiang@xxxxxxxxx>]

Thanks to Min & Dan.

Min, I am running an OLTP workload. I have no clue about high number
of exceptions and interrupts now.

Still, I think it is appealing to have consistency between system time
and GEMS time. And it maybe easy. What we need to do is to deceive
Solaris(or other OSs) that GEMS time is the correct time. Based on my
understanding on Solaris and Ultrasparc, we can do this through
updating %tick and %stick register. Here, I assume all time-related
system calls are based on %tick/stick registers' value.

Any comment on my proposal?


FYI, Some discussion containing information about %tick/stick register
on ultrasparc processor

http://www.opensolaris.org/jive/thread.jspa?threadID=5333&tstart=0




On 3/29/06, Dan Gibson <degibson@xxxxxxxx> wrote:
> That is consistent with my understanding as well. When opal is used,
> simics is *stepped* whenever opal simulates a commit. When only Ruby is
> uses, Simics is stalled when memory requests are issued. Each non-memory
> instruction takes one cycle, provided it does not miss in the i-cache.
>
> Min Xu (Hsu) wrote:
> > correct me if I am wrong, when opal is used, simics does
> > not get stalled by opal (and ruby is not installed as a
> > timing interface in simics). Each simics instruction
> > takes one simics cycle.
> >
> > On Wed, 29 Mar 2006 Dan Gibson wrote :
> >
> >> Simics cycles also count the time that a given processor is stalled
> >> waiting on a memory request. An L2 miss usually constitutes a few
> >> hundred simics cycles, though the exact number changes greatly depending
> >> on configuration, and whether or not Opal is used in conjunction with Ruby.
> >>
> >> Min Xu (Hsu) wrote:
> >>
> >>> Simics cycle number includes both dynamic
> >>> instructions and exceptions/interrupts.
> >>>
> >>> When running with opal, each dynamic instruction
> >>> increment simics cycle number by 1, but the
> >>> same instruction may have much longer latency
> >>> in terms of the "GEMS cycle". The reason that
> >>> simics cycle is larger than the number of dynamic
> >>> instructions in your experiment is that simics
> >>> cycle number also counts the exceptions and
> >>> interrupts. I am curious what workload you are
> >>> using, because the number of exceptions and
> >>> interrupts seems high.
> >>>
> >>> We are aware that because simics cycle
> >>> number don't really reflect the instruction
> >>> latency, interrupts are perhaps delivered
> >>> more frequent than it needs to be.
> >>>
> >>> On Wed, 29 Mar 2006 Weihang Jiang wrote :
> >>>
> >>>
> >>>> I used both.
> >>>>
> >>>> On 3/29/06, Min Xu (Hsu) <xu@xxxxxxxxxxx> wrote:
> >>>>
> >>>>
> >>>>> Did you use Opal or just Ruby only? It matters.
> >>>>>
> >>>>> On Wed, 29 Mar 2006 Weihang Jiang wrote :
> >>>>>
> >>>>>
> >>>>>> Hi,
> >>>>>>   Can anybody help me understand the relation between SIMICS
> >>>>>> cycle and GEMS cycle.
> >>>>>>
> >>>>>>   SIMICS cycle means the number of cycles SIMICS thinks the
> >>>>>> simulation has lasted, which can be calculated through
> >>>>>> calling SIM_cycle_count() at the beginning and the end of
> >>>>>> one simulation.
> >>>>>>   GEMS cycle is referring to the number of cycles opal/ruby
> >>>>>> has advanced.
> >>>>>>
> >>>>>>   Understanding the relation between SIMICS cycle and GEMS
> >>>>>> cycle is important for utilizing system level profiling
> >>>>>> tools. For example, vmstat reports both number of events
> >>>>>> (e.g. bi, bo) and relative execution time (e.g. us,sy,id).
> >>>>>> Other profiling tools report absolute execution time.
> >>>>>>
> >>>>>>   I did a small experiment to testify the relation. I ran
> >>>>>> SIMICS+GEMS with two different cache configurations for
> >>>>>> 10,000,000 GEMS cycles.
> >>>>>>   In experiment 1, using fast cache, 407,808 instructions
> >>>>>> have been executed and the SIMICS cycle number is 1,711,569.
> >>>>>> In experiment 2, using slow cache, 401,245 have been
> >>>>>> executed. However, the SIMICS cycle number is 1,664,671
> >>>>>> (different from exp1).
> >>>>>>
> >>>>>>    Based on this experiment, my understanding is that,
> >>>>>> SIMICS cycle is not an accurate measurement and those system
> >>>>>> level profiling tools can not be used without care.
> >>>>>>
> >>>>>>    So, I have 2 questions:
> >>>>>>
> >>>>>> 1. Is my understanding correct?
> >>>>>> 2. How much effort does it require to let SIMICS cycle have
> >>>>>> more sense(i.e. let SIMICS cycle == GEMS cycle)?
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Weihang Jiang,  UIUC
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Gems-users mailing list
> >>>>>> Gems-users@xxxxxxxxxxx
> >>>>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Gems-users mailing list
> >>>>> Gems-users@xxxxxxxxxxx
> >>>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> Weihang Jiang
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Gems-users mailing list
> >>> Gems-users@xxxxxxxxxxx
> >>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>>
> >>>
> >> _______________________________________________
> >> Gems-users mailing list
> >> Gems-users@xxxxxxxxxxx
> >> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >>
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> >
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>


--
Weihang Jiang