Re: [Gems-users] Simulated machine execution time

[Philip Garcia <pcgarcia@xxxxxxxx>]

There will end up being a change on the overhead of the kernels  
scheduler.  The kernel (at least the Linux kernel) is written to  
perform a timer interrupt a constant number of times per second  
(defined by the constant HZ in the kernel).  Generally this is set to  
1000, so a 75MHz simulated machine will have 10 times more timer  
interrupts than a 750MHz machine and so forth.  This could impact  
timing as scheduling might occur more frequently etc.  However I  
don't think it's a major concern, as the HZ value defined in the  
kernel really hasn't changed, and was likely set to 1000 on a 75MHz  
processor.  Assuming the overhead of the OS interrupt is small this  
won't make too much of a difference.  However experiments would need  
to be performed to see if this really effects a given applications.
As for I/O events, it can skew those numbers, but Simics doesn't  
really perform timing-accurate I/O simulation in the first place, so  
if you're running heavily I/O dependent applications, the results  
from Simics/GEMS would likely be off anyhow.  Therefore the HZ value,  
or setting of the simics CPU frequency would not really matter when  
relating to I/O.
Phil
On Oct 23, 2007, at 3:50 PM, Mike Marty wrote:

> I was wondering if the frequency of clock-based interrupts could  
> impact
> the scheduling of various OS events (like cross-calls, TLB shootdowns,
> etc) and even the scheduling of application threads.  I'm not  
> really an
> OS guy, so I'm not sure.  But this is what I had in mind
>
> --Mike
>
>
> Greg Byrd wrote:
> > Agreed.  Clock-based interrupts will occur less frequently (i.e.,  
> > more cycles in
> > between).  I/O timing will look different.  Are there other  
> > differences that
> > you've encountered that I haven't considered?  (This isn't a  
> > rhetorical question
> > -- I'm really interested in what others think about this.)
> >
> > ...Greg
> >
> >
> > Mike Marty wrote:
> > > > I tend to use the "sarek" configuration.  In
> > > > $SIMICS/home/sarek/sarek-common.simics, there's a python  
> > > > variable "cpu_freq"
> > > > that sets this parameter.  It defaults to 75.
> > > >
> > > > Also, at least for the Ultrasparc processor, it's saved when you  
> > > > do a simics
> > > > checkpoint.  Look for the string "freq_mhz".  You can just  
> > > > change this (for all
> > > > processors) in the checkpoint file directly.
> > > >
> > > > Note that changing this only affects time from the Simics point  
> > > > of view.  It
> > > > doesn't have any effect on Ruby cycles.
> > > Except that it could change the execution path that a program takes
> > >
> > > --mike
> > >
> > >
> > > _______________________________________________
> > > Gems-users mailing list
> > > Gems-users@xxxxxxxxxxx
> > > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > > Use Google to search the GEMS Users mailing list by adding  
> > > "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> >
> > --------------------------------------------------------------------- 
> > ---
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding  
> > "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding  
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.