[Gems-users] memoryBits: 0 memorySizeBits: 29 Address: [0xff164000, line 0xff164000]error: limit exceeded


Date: Tue, 24 Mar 2009 14:35:04 -0500
From: "Berkin Ozisikyilmaz" <boz283@xxxxxxxxxxxxxxxxxxxx>
Subject: [Gems-users] memoryBits: 0 memorySizeBits: 29 Address: [0xff164000, line 0xff164000]error: limit exceeded
Hello again, this is the 3rd time that I am trying to get a response for
this mail. It's been over 2 weeks that I originally posted the problem. I
know that it is not always to give support to people, there are more urgent
stuff that needs to be done. 

I just want to know if people had similar problems like this. Is it a
problem on the simic part, gems part or the application part?

Thanks
Berkin

-----Original Message-----
From: Berkin Ozisikyilmaz [mailto:boz283@xxxxxxxxxxxxxxxxxxxx] 
Sent: 2009-03-17 16:03
To: 'Gems Users'
Subject: RE: [Gems-users] Simics 2.2 vs Simics 3.0 statistics difference

To revive this topic, does anyone know why I might sometimes be getting this
error and not other times?

Thanks
Berkin

memoryBits: 0 memorySizeBits: 29 Address: [0xff164000, line
0xff164000]error: limit exceeded.  dataBlockBits: 6 memoryModuleBlocks:
8388608 index: 66869504 failed assertion 'index <
RubyConfig::memoryModuleBlocks()' at fn integer_t
Address::memoryModuleIndex() const in common/Address.h:210 failed assertion
'index < RubyConfig::memoryModuleBlocks()' at fn integer_t
Address::memoryModuleIndex() const in common/Address.h:210
At this point you might want to attach a debug to the running and get to the
crash site; otherwise press enter to continue PID: 7241

-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx]
On Behalf Of Berkin Ozisikyilmaz
Sent: 2009-03-11 10:55
To: 'Gems Users'
Subject: Re: [Gems-users] Simics 2.2 vs Simics 3.0 statistics difference

For a crashing configuration, I ran it only 10000 cycles with opal to get
quick results. 
I had set the ruby0.setparam g_MEMORY_SIZE_BYTES 536870912. And the
phys_mem0.map is shown below. Both of the values agree. 

simics> phys_mem0.map
base               object               fn offs               length
0x0000000000000000 memory0               0 0x0                0x20000000

0x000007fff07ffff0 hfs0                  0 0x0                0x10    


Regards,
Berkin

-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx]
On Behalf Of Dan Gibson
Sent: 2009-03-11 08:07
To: Gems Users
Subject: Re: [Gems-users] Simics 2.2 vs Simics 3.0 statistics difference

To what value are you setting g_MEMORY_SIZE_BYTES?
What is the output from the following Simics command after loading
your checkpoint(s)?
phys_mem0.map

Regards,
Dan

On Tue, Mar 10, 2009 at 10:32 PM, Berkin Ozisikyilmaz
<boz283@xxxxxxxxxxxxxxxxxxxx> wrote:
> I don?t change anything of the configuration. I have seen the problem
occur
> in the same image, and for example have 4 processors. I start an
application
> with 2 threads, and another 2 threads, the simulation continues very well.
> However, I run the first app with 3 threads and then the other with single
> thread. I get this error. I don?t know why this happens, usually I change
> the "c instruction" amount a little after I start the apps and load
> ruby/opal. I think the memory might get somehow corrupted. I don?t have
> enough knowledge about the internals.
>
> Thanks
> Berkin
>
> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx]
> On Behalf Of Dan Gibson
> Sent: 2009-03-10 23:04
> To: Gems Users
> Subject: Re: [Gems-users] Simics 2.2 vs Simics 3.0 statistics difference
>
> In addition to what Phil said (i.e. that g_MEMORY_SIZE_BYTES might not
> be set correctly), this also happens when the physical address space
> is non-contiguous, i.e. when Simics models multiple memory controllers
> and the physical addresses for memory isn't one big range (e.g.,
> 0-0xfffffff UNION 0x30000000-0x3fffffff), which can happen when
> multiple UltraSPARC-III 'boards' are used, or multiple serengeti
> chassis, or both. I can't imagine why it would happen under one
> version and not the other, however.
>
> Regards,
> Dan
>
> On Tue, Mar 10, 2009 at 9:56 PM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:
>> It sounds like you didn't set the memory to be the same size in simics
>> 2.2 vs simics 3.0, but I could be wrong.  I think this error occurs
>> when you have a physical memory address greater (or less than or
>> whatever, I can't remember the ultrasparc memory model) than what
>> rubys is expecting.  I imagine someone from the GEMS groups would know
>> more about it, but I know I've seen that error in the past.
>>
>> Phil
>> On Mar 10, 2009, at 5:15 PM, Berkin Ozisikyilmaz wrote:
>>
>>> I was trying Phil's idea of creating a checkpoint after applications
>>> start
>>> running and then load ruby/opal and simulate for 100mil
>>> instructions. I get
>>> this error when using Simics 3.0 (which hadn?t occurred for the same
>>> scenario with simics2.2), which I have seen previously and don?t
>>> know the
>>> exact meaning (I am restarting the simulation but I think this error
>>> will
>>> occur again).
>>>
>>> memoryBits: 0 memorySizeBits: 29 Address: [0xff164000, line
>>> 0xff164000]error: limit exceeded.  dataBlockBits: 6
>>> memoryModuleBlocks:
>>> 8388608 index: 66869504
>>> failed assertion 'index < RubyConfig::memoryModuleBlocks()' at fn
>>> integer_t
>>> Address::memoryModuleIndex() const in common/Address.h:210
>>> failed assertion 'index < RubyConfig::memoryModuleBlocks()' at fn
>>> integer_t
>>> Address::memoryModuleIndex() const in common/Address.h:210
>>> At this point you might want to attach a debug to the running and
>>> get to the
>>> crash site; otherwise press enter to continue
>>> PID: 7241
>>>
>>> Abort (SIGABRT) in main thread
>>> The simulation state has been corrupted. Simulation cannot continue.
>>> Please restart Simics.
>>> Starting command line. (May have skipped commands in script files.)
>>>
>>>
>>> -----Original Message-----
>>> From: gems-users-bounces@xxxxxxxxxxx
> [mailto:gems-users-bounces@xxxxxxxxxxx
>>> ]
>>> On Behalf Of Dan Gibson
>>> Sent: 2009-03-09 10:34
>>> To: Gems Users
>>> Subject: Re: [Gems-users] Simics 2.2 vs Simics 3.0 statistics
>>> difference
>>>
>>> Try this with Ruby only.
>>> Verify both stats files show similar instruction fetch statistics.
>>>
>>> Regards,
>>> Dan
>>>
>>> On Sun, Mar 8, 2009 at 9:28 PM, Philip Garcia <pcgarcia@xxxxxxxx>
>>> wrote:
>>>> the c 200000000 might be causing problems between the two versions of
>>>> simics.  Try launching the simulation (in simics only) in 2.2, and
>>>> after the 200M cycles (or more if you want, this should go fast),
>>>> save
>>>> a checkpoint.  Then load that same checkpoint with simics/gems for
>>>> both the 2.2 and 3.0 case.  That way you know all processors are
>>>> starting at the exact same point in each situation.
>>>>
>>>> Phil
>>>> On Mar 8, 2009, at 6:24 PM, Berkin Ozisikyilmaz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am first launching the applications and continuing 200million
>>>>> instructions
>>>>> which seem to be enough to get the applications running. Yes for
>>>>> this
>>>>> testing I am running 100million, and aware that it might not be long
>>>>> enough
>>>>> to be representative. I am using a quad-core machine and it takes
>>>>> 16-24
>>>>> hours to run only this 100million instructions (its just a side note
>>>>> regarding the performance). So according to the performance of the
>>>>> current
>>>>> simulations 2billion instruction execution will take ~20x20hours=400
>>>>> hours
>>>>> about 17 days just for a configuration. Is this reasonable?
>>>>>
>>>>> I have run the same script multiple times on Simics 2.2 and
>>>>> currently
>>>>> running them under Simics 3.0. The results from the simics 2.2 are
>>>>> exactly
>>>>> the same in between themselves. I have copied the disk image,
>>>>> checkpoint,
>>>>> scripts from my Simics2.2 directory to 3.0. Both Simics and Gems are
>>>>> compiled with the same compiler.
>>>>>
>>>>> Thanks
>>>>> Berkin
>>>>>
>>>>> -----Original Message-----
>>>>> From: gems-users-bounces@xxxxxxxxxxx
>>> [mailto:gems-users-bounces@xxxxxxxxxxx
>>>>> ]
>>>>> On Behalf Of Philip Garcia
>>>>> Sent: 2009-03-08 18:13
>>>>> To: Gems Users
>>>>> Subject: Re: [Gems-users] Simics 2.2 vs Simics 3.0 statistics
>>>>> difference
>>>>>
>>>>> It appears that you are launching your jobs when you have ruby and
>>>>> opal loaded, and therefore measuring both the execution time of your
>>>>> jobs and the OS overhead of getting the jobs ready to execute.   If
>>>>> simics 2.2 and simics 3.0 are not starting at the exact same point
>>>>> in
>>>>> time, this alone will cause large variabilities in your execution
>>>>> time.  Personally, I recommend getting all programs you want to
>>>>> execute started and executing before you start measuring with
>>>>> simics/
>>>>> opal.    In addition, it appears that you're only running gems for
>>>>> 100
>>>>> million cycles.  If workloads are not at the same point in time,
>>>>> this
>>>>> is likely not long enough of a sample to be representative of the
>>>>> programs you are attempting to measure.  Have you ensured that all
>>>>> your applications have reached the same point in each test?  Also,
>>>>> do
>>>>> they both use the same default simics configuration files?  There
>>>>> are
>>>>> many parameters that could cause such a large discrepancy in run
>>>>> times
>>>>> for such short tests.  In my experience runs between simics 2.2 and
>>>>> 3.0 have experienced some variability (when issued from the same
>>>>> checkpoint), but the difference is negligible over a 2 billion cycle
>>>>> execution time.
>>>>>
>>>>> Phil
>>>>> On Mar 8, 2009, at 3:56 PM, Berkin Ozisikyilmaz wrote:
>>>>>
>>>>>> I am running ./simics -stall myscript.simics
>>>>>>
>>>>>> My script is this
>>>>>>
>>>>>> read-configuration magicstart-micro
>>>>>> con0.input "./example_O3 -i ./color100 -p 1 &\n"
>>>>>> con0.input "./example_O3 -i ./color100 -f -p 3 &\n"
>>>>>> con0.input "./para_hop 61440 ./particles_0_64.flp 64 16 -1 2 &\n"
>>>>>> con0.input "./scalparc para_F26_A32-D125K/F26-A32-D125K.tab 125000
>>>>>> 32 2 10
>>>>>> &\n"
>>>>>> c 200000000
>>>>>> cpu-switch-time 1
>>>>>> instruction-fetch-mode instruction-fetch-trace
>>>>>> istc-disable
>>>>>> dstc-disable
>>>>>> load-module ruby
>>>>>> ruby0.setparam g_NUM_PROCESSORS 16
>>>>>> ruby0.setparam g_MEMORY_SIZE_BYTES 536870912
>>>>>> ruby0.setparam g_PROCS_PER_CHIP 16
>>>>>> ruby0.setparam g_NUM_MEMORIES 1
>>>>>> ruby0.setparam NUMBER_OF_VIRTUAL_NETWORKS 5
>>>>>> ruby0.init
>>>>>> load-module opal
>>>>>> opal0.init
>>>>>> opal0.sim-start "1-3-2-10-repeat2.opal"
>>>>>> opal0.sim-step 100000000
>>>>>> opal0.stats
>>>>>> ruby0.dump-stats "1-3-2-10-repeat2.ruby"
>>>>>> opal0.sim-stop
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: gems-users-bounces@xxxxxxxxxxx
>>>>> [mailto:gems-users-bounces@xxxxxxxxxxx
>>>>>> ]
>>>>>> On Behalf Of Dan Gibson
>>>>>> Sent: 2009-03-08 15:38
>>>>>> To: Gems Users
>>>>>> Subject: Re: [Gems-users] Simics 2.2 vs Simics 3.0 statistics
>>>>>> difference
>>>>>>
>>>>>> Berkin,
>>>>>>
>>>>>> How are you deciding how long to run your simulations? Are you
>>>>>> using
>>>>>> magic breakpoints before/after the benchmark? Or are you just
>>>>>> running
>>>>>> for a fixed number of instructions/steps/cycles?
>>>>>>
>>>>>> Can you please verify that you are setting both versions to emulate
>>>>>> instruction fetch?
>>>>>> (Simics command: instruction-fetch-mode instruction-fetch-trace)
>>>>>>
>>>>>> Can you also verify that both runs use cpu-switch-time 1?
>>>>>> (Simics command: cpu-switch-time 1)
>>>>>>
>>>>>> Regards,
>>>>>> Dan
>>>>>>
>>>>>> On Sun, Mar 8, 2009 at 2:05 PM, Berkin Ozisikyilmaz
>>>>>> <boz283@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Since my current licenses are expiring soon. I have been trying to
>>>>>>> run the
>>>>>>> same scripts for the same experiments with the checkpoints created
>>>>>>> in
>>>>>> simics
>>>>>>> 2.2 in simics 3.0. The total statistics seems to be significantly
>>>>>> different.
>>>>>>> I am just posting a part of the logs to show the difference. Has
>>>>>>> anyone
>>>>>>> observed this? Is there a solution? Should I contact Simics forum
>>>>>>> and what
>>>>>>> should I tell?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Berkin
>>>>>>> PS: If you need more details I can attach the whole logs too.
>>>>>>>
>>>>>>>
>>>>>>> Simics 3.0:
>>>>>>> Ruby_current_time: 56966471
>>>>>>> Ruby_start_time: 1
>>>>>>> Ruby_cycles: 56966470
>>>>>>>
>>>>>>> mbytes_resident: 415.297
>>>>>>> mbytes_total: 443.906
>>>>>>> resident_ratio: 0.935568
>>>>>>>
>>>>>>> Total_misses: 638457
>>>>>>> total_misses: 638457 [ 76793 26643 472 14111 92155 440 2386 6512
>>>>>>> 9838
>>>>>> 11455
>>>>>>> 8045 793 279752 6949 91696 10417 ]
>>>>>>> user_misses: 143334 [ 21434 11522 0 0 41821 0 1082 0 8810 10365
>>>>>>> 2177 0 0 0
>>>>>>> 44952 1171 ]
>>>>>>> supervisor_misses: 495123 [ 55359 15121 472 14111 50334 440 1304
>>>>>>> 6512 1028
>>>>>>> 1090 5868 793 279752 6949 46744 9246 ]
>>>>>>>
>>>>>>> instruction_executed: 1942683921 [ 100000003 124129441 163319276
>>>>>>> 165435219
>>>>>>> 53861776 163460755 161657288 175769500 38246531 38301267 159181278
>>>>>> 168205246
>>>>>>> 45314492 170155942 53902511 161743396 ]
>>>>>>> simics_cycles_executed: 32 [ 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 ]
>>>>>>> cycles_per_instruction: 0.469177 [ 0.569665 0.458928 0.348804
>>>>>>> 0.344343
>>>>>>> 1.05764 0.348502 0.35239 0.324098 1.48945 1.48733 0.357872
>>>>>>> 0.338672
>>>>>> 1.25714
>>>>>>> 0.33479 1.05684 0.352203 ]
>>>>>>> misses_per_thousand_instructions: 0.328647 [ 0.76793 0.214639
>>>>>>> 0.00289004
>>>>>>> 0.0852962 1.71095 0.00269178 0.0147596 0.0370485 0.257226 0.299076
>>>>>> 0.0505399
>>>>>>> 0.00471448 6.17357 0.040839 1.70115 0.0644045 ]
>>>>>>>
>>>>>>> --------------------
>>>>>>> Simics 2:
>>>>>>> Ruby_current_time: 27449208
>>>>>>> Ruby_start_time: 1
>>>>>>> Ruby_cycles: 27449207
>>>>>>>
>>>>>>> mbytes_resident: 337.574
>>>>>>> mbytes_total: 360.633
>>>>>>> resident_ratio: 0.936082
>>>>>>>
>>>>>>> Total_misses: 296966
>>>>>>> total_misses: 296966 [ 21740 589 369 7149 35485 266 349 8086 5925
>>>>>>> 134268
>>>>>>> 39354 635 6461 33942 545 1803 ]
>>>>>>> user_misses: 64611 [ 5863 0 0 474 16339 0 0 0 5232 0 20015 0 1669
>>>>>>> 15019 0
>>>>>> 0
>>>>>>> ]
>>>>>>> supervisor_misses: 232355 [ 15877 589 369 6675 19146 266 349 8086
>>>>>>> 693
>>>>>> 134268
>>>>>>> 19339 635 4792 18923 545 1803 ]
>>>>>>>
>>>>>>> instruction_executed: 935171606 [ 17858141 78628658 78723317
>>>>>>> 78953073
>>>>>>> 27873028 78695970 78809154 85782525 18431579 21706482 25875467
>>>>>>> 79044210
>>>>>>> 77362284 27932361 78666708 80828649 ]
>>>>>>> simics_cycles_executed: 32 [ 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 ]
>>>>>>> cycles_per_instruction: 0.469633 [ 1.53707 0.349099 0.34868
>>>>>>> 0.347665
>>>>>>> 0.984795 0.348801 0.3483 0.319986 1.48925 1.26456 1.06082 0.347264
>>>>>> 0.354814
>>>>>>> 0.982703 0.34893 0.339597 ]
>>>>>>> misses_per_thousand_instructions: 0.317552 [ 1.21737 0.00749091
>>>>>>> 0.0046873
>>>>>>> 0.0905475 1.27309 0.0033801 0.00442842 0.0942616 0.321459 6.18562
>>>>>>> 1.5209
>>>>>>> 0.00803348 0.0835161 1.21515 0.00692796 0.0223064 ]
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>>
>>
>> _______________________________________________
>> 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.


[← Prev in Thread] Current Thread [Next in Thread→]
  • [Gems-users] memoryBits: 0 memorySizeBits: 29 Address: [0xff164000, line 0xff164000]error: limit exceeded, Berkin Ozisikyilmaz <=