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

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

Hi Min,
    Thank you for your comments. Yes, only modifying tick/stick
registers does not make system behavior 100% consistent with GEMS
timing. But the bottom line is, it can enable the system level
profiling tools(e.g. DTrace) to reflect on GEMS timing. Otherwise, we
need to do the same jobs inside GEMS to profile system behavior.
Secondly, it will reduce the frequency of interrupt handlers, which
are relying tick,stick,tick_cmp,stick_cmp registers.
    Any comments are welcome.

On 3/29/06, Min Xu (Hsu) <xu@xxxxxxxxxxx> wrote:
> Weihang,
>
> You are very welcome.
>
> Your proposal is an interesting idea. I have not thought about
> it. Note that, in addition to the %tick and %stick registers,
> it might be more important to take care of the devices, e.g.
> RTC. These devices register themselves in the simics time queue.
> But the simics time queue is advanced based on the simics
> cycle number. The devices are woken up in terms of simics
> time and they interrupt the CPU.
>
> In fact, I am not sure these tick registers affect the behavior
> of solaris kernel or most applications. These registers are
> more often used in time measurement with high precision, aren't they?
>
> -Min
>
> On Wed, 29 Mar 2006 Weihang Jiang wrote :
> > 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
> >
> > _______________________________________________
> > 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