hi, I am using Opal+Ruby.i ran PARSEC benchmark using 2GHz and 75GHz machine, but i did not see any major simulation time(ie wall clock time) reduction. Another thing is that when i use 75GHz machine i see more cache lines when i save ruby $ states using "save-caches" command. I guess this is due to the frequent execution of OS code.
Regards, Muhammad abid
From: Dan Gibson <degibson@xxxxxxxx>
To: Gems Users <gems-users@xxxxxxxxxxx>
Sent: Tuesday, February 16, 2010 21:50:52
Subject: Re: [Gems-users] Change in cpu frequency - question
I run at 2GHz for most of my work. I made my 2GHz checkpoints by booting the machine at that frequency. To me, the 2GHz checkpoints seem slower and less responsive than the 75MHz checkpoints, because of the I/O issues we've discussed. Yes, booting took a while. That is the only difference I have personally observed.
Regards, Dan On Mon, Feb 15, 2010 at 10:04 PM, Pradeep Ramachandran <pramach2@xxxxxxxx> wrote:
Thanks for the stick_cmpr patch. It seemed to work well for me.
I recently tried another experiment where I booted up a machine at 2GHz (by changing the configuration file used to boot up the system), and then I tried to run a distributed workload, and things seemed to work just fine! I queried inside the simulation opensolaris and it looked like the processor frequency registered is 2GHz. I am curious whether other people have tried booting up the machine at higher frequency (instead of the default 75MHz), or have only tried changing the frequency in the checkpoint configuration file.
Thanks, Pradeep. On Feb 8, 2010, at 5:56 PM, Dan Gibson wrote: We could easily make this an unsupported patch, available with citation on GEMS the download page. All I need is a patch file.
Regards,
Dan
On Mon, Feb 8, 2010 at 5:44 PM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:
if you want, I could get together sometime, with you, or someone else working on Opal to see if we can get these changes working on one of your branches of opal running solaris. I don't have any of that locally, and my opal files have been modified enough from the vanilla install. However, it would likely be useful for gems to have code to support this, as well as fixed code that does context tracking.
Phil On Feb 8, 2010, at 5:41 PM, Dan Gibson wrote: Neat. I'd be interested in learning whether this hoses Solaris or not.
On Mon, Feb 8, 2010 at 4:42 PM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:
for the first part of our work, we modified pseq.C. We have a variable called m_time_per_1_ms, which is just the number of cycles in 1ms of simulated cycle time. We use this, because linux typically expects a timer interrupt every mS. We added this variable to the rubyconfig class. Also note that our current implementation is not SMT aware, but should be simple to modify for that. This modification just checks if we should have another timer interrupt, and if so tells simics to post the event in 2 cycles.
At the end of AdvanceCycle We have the following code:
tick_t curr_time = system_t::inst->getGlobalCycle();
//If it has been almost 1mS since the last interrupt, we want to set the tick cmpr register
//if(curr_time %100000 == 0){
// DEBUG_OUT("advanceCycle:: curr_time = %llu, last_intr_time = %llu, m_time_per_1ms = %llu\n",curr_time,m_last_interrupt4e_time, m_time_per_1ms);
//}
//Phil: SMT has to be disabled. This is really ugly!!! Someone needs to fix this...
if((curr_time - m_last_interrupt4e_time > (m_time_per_1ms - 3)) && !m_tick_interrupt_pending ){
tick_t curr_tick = SIM_read_register(M_PSTATE->getSimicsProcessor(0), 39);//get tick register
//print info
DEBUG_OUT("T=%10llu :: pseq_t[%d]:advanceCycle last interrupt = %llu, curr_tick = %llu, set tick_cmpr\n",curr_time,m_id,m_last_interrupt4e_time, curr_tick);
//Write curr_tick + 2 so that the interrupt will happen in two SIMICS ticks
SIM_write_register(M_PSTATE->getSimicsProcessor(0), 41, curr_tick+2);
//set tick_interrupt_pending so that we don't update the tick_cmpr register again
//before the interrupt happens
m_tick_interrupt_pending = true;
}
}
We then modified the pseq_t::postException method to check for the timer interrupt trap. This way we can reset the tick compare register to a very large value so it only goes off when we specify (in advance cycle):
//***************
//tick hack
if(exception == Trap_Interrupt_Level_14){ //the trap type for "4e"
m_tick_interrupt_pending = false;
tick_t curr_time = system_t::inst->getGlobalCycle();
tick_t curr_tick = SIM_read_register(M_PSTATE->getSimicsProcessor(proc), 39);//get TICK register
SIM_write_register(M_PSTATE->getSimicsProcessor(proc), 41, curr_tick+99000000);
int delta_time = (curr_time - m_last_interrupt4e_time);
int delta_tick = (curr_tick - m_last_interrupt4e_tick);
m_last_interrupt4e_time = curr_time;
m_last_interrupt4e_tick = curr_tick;
m_last_interrupt4e_dtime = delta_time;//some calculation for delta time
m_last_interrupt4e_dtick = delta_tick;//some calculation for delta tick
DEBUG_OUT("T=%10llu ::pseq_t[%d] postException, save last_time = %llu, last_tick = %llu\n",curr_time,m_id, curr_time, curr_tick);
}
Lastly, we reset the register when the OS is switched onto the CPU, and a tick interrupt was pending. This is in the contextSwitch method.
if(new_context){
//DEBUG_OUT("new_context = %x ",new_context);
if(m_primary_ctx[proc] == 0 ){
//DEBUG_OUT("m_primary_ctx is the OS ");
if(!m_tick_interrupt_pending && thread_ctx){
tick_t curr_tick = SIM_read_register(M_PSTATE->getSimicsProcessor(proc), 39); //get_tick_reg
//write the tick_cmpr register as 99M more than the current value, but only if
//we haven't just set it to something to cause an interrupt
SIM_write_register(M_PSTATE->getSimicsProcessor(proc), 41, curr_tick + 99000000);
if(thread_ctx){
DEBUG_OUT("ContextSwitch::pseq_t[%d] set tick_cmpr to %llu\n",proc,curr_tick+99000000);
}
}
}
These changes seem to be sufficient to make linux work properly, and it does allow timer interrupts to still go off. One needs to be careful to not completely disable timer interrupts, or the OS can and likely will fail to function properly.
Phil
On Feb 8, 2010, at 4:09 PM, Pradeep Ramachandran wrote: > I used the pointer given by Dan to reset the stick_cmpr registers from simics, and this masks out the Timer interrupt (thanks for the pointer Dan!). However, I just want to make doubly sure that there isn't something else that I should be doing that I'm not. If you can paste the snippet of code that you guys use, it would be very useful for me to cross-check.
> > Thanks, > Pradeep. > > On Feb 7, 2010, at 2:19 PM, Philip Garcia wrote: > >> I can look up the hack we use, however I can't really guarantee it will work for you. I'm using GEMs on a bagle target machine which is based on an UltraSparc II processor, and not a III. I'll try to post some code later tonight or tomorrow.
>> >> Phil >> On Feb 7, 2010, at 2:05 PM, Pradeep Ramachandran wrote: >> >>> >>> On Feb 6, 2010, at 7:00 PM, Philip Garcia wrote: >>> >>>> You can get around the 75MHz clock issue by stalling the timer interrupts until you want them. This can be done by manipulating the tick and tick compare register so that it goes off at specified times.
>>>> >>> >>> I have been digging around to find information on the tick and tick compare registers (%stick and %stick_cmpr), but I have found hardly any info (even the SPARCV9 manual doesn't list them!). Do you have any pointers on how the registers are used? As I'd mentioned before, I would like to make the timer interrupts less frequent so that I simulate a 2GHz-like balanced machine with the 75MHz simics system, for which I need to make timer interrupts far less frequent.
>>> >>> Thanks, >>> Pradeep. >>> _______________________________________________ >>> 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.
> _______________________________________________ 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.
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________
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.
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
_______________________________________________
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.
-- http://www.cs.wisc.edu/~gibson [esc]:wq!
New Email names for you!
Get the Email name you've always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}