Re: [Gems-users] OS interrupts ...

[Stamatis Kavadias <kavadias@xxxxxxxxxxxx>]

Hello Philip,

    Thanks for the fast reply. It seems you are absolutely right.
These tick interrupts where what I was observing. Once I have
set the tick_cmpr (and stick_cmpr) to a very large value the
interrupts stopped. I did this directly through Simics - I am not
using Opal. It seems though, that the interrupts actually stopped
after a period of about 960000 cycles after changing the (s)tick_cmpr
registers during which interrupts persist ... Anyway, I will find a
way to skip this interval.

    Thank you very much again.

Stamatis


Philip Garcia wrote:

It is possible to modify the OS behavior (at least under linux, I'm  
not sure about the behavior under Solaris) by modifying the tick and  
tick_cmpr registers so that they go off only when you want them to.  I  
am not too familiar with how we handle it (as one of my labmates has  
modified opal so that it's handled properly).  There are actually two  
problems involved here though, the first being that Simics is using a  
relatively slow clock frequency, but also the tick register is  
incremented every time simics completes an instruction, and not every  
time simics completes a cycle.   This can cause problems with some  
codes.  Our solution involved setting the tick_cmpr register to a very  
high number initially (so that we never reach it), and then when we've  
calculated that enough cycles have passed, we modify the tick_cmpr  
register (on the relevant processor) to be a couple cycles (really  
intructions) from the tick register.  I can't say for sure if this  
technique will work under Solaris, but I imagine these are the  
interrupts that you are seeing.

Phil
On Feb 18, 2009, at 11:29 PM, Stamatis Kavadias wrote:

  

Hello all,

   I am using a large multiprocessor system in Simics (Serengeti)   
to drive
GEMS and running some microbenchmarks to evaluate my hardware
mechanisms. I have a problem with the OS (Solaris 10) interfering with
my measurements. I am using a so-called real time mode of Solaris to
reduce scheduler activations, but every about 750000 Simics cycles
I see interrupts on many (if not all) processors over a period of  
about
35000 cycles. I assume that because of the low clock frequency of the
Simics configuration --in order for the simulation to be responsive to
interactive input before I load ruby-- the OS being activated every
1ms=750000 cycles@75MHz produces this effect. I have set the quantum
to millions but this is not helping. I have also put all processors  
but
processor 0 to a P_NOINTR mode so that they do not receive interrupts
but still.
   I am sure that people must have a way around this since GEMS has
been used for many architectural studies. I suppose it must be almost
impossible to install Solaris with a reasonably large clock frequency,
because it would take forever... If I try to boot the machine with  
the -r
flag, can I change the clock frequency?? How long would that take?
Is it possible that this is a side effect of the real time mode I am  
using
and the OS will not get involved so often if I let alone the normal
time sharing scheduler??
Please help me out with this... I am sure I am doing something stupid.

Thanks in advance,


Stamatis

_______________________________________________
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.