Re: [Gems-users] Problem running a workload


Date: Thu, 8 Apr 2010 00:02:06 +0430
From: Mahmood Naderan <mahmood.nt@xxxxxxxxx>
Subject: Re: [Gems-users] Problem running a workload
Yes, you got my intent and my question was exactly what you said. The
magic-break-enable is what I am looking for.

On 4/7/10, Dan Gibson <degibson@xxxxxxxx> wrote:
> I think what you are asking is:
> "How do I know I am simulating long enough to cover the entire run of the
> workload, but not so long that I'm simulating well after its completion?"
>
> If you are NOT asking that question, re-word your question so I understand
> it.
>
> Here is the answer to the question above. It has two parts.
> 1. It is a common practice to not simulate workloads to their completion --
> it simply takes too long.
> 2. To ensure you do not over-simulate, we recommend you insert magic
> breakpoints after your workloads, which will stop the simulation
> automatically if reached.
>
> You will find plenty of information on magic breakpoints if you search this
> list. (e.g., from http://www.cs.wisc.edu/gems/doc.html)
>
> Regards,
> Dan
>
> On Wed, Apr 7, 2010 at 1:36 AM, Mahmood Naderan <mahmood.nt@xxxxxxxxx>wrote:
>
>> Although the previous question has not been answered yet, one more
>> important question is now raised.
>> Consider that running the barnes workload take 2 second on simics as
>> warm-up. Since I don't know how many cycles it took, it is ambiguous for
>> me
>> how to determine the number of cycles in "opal0.sim-step N". Two possible
>> cases are:
>> 1- if (N < number of actual cycles in 2 seconds run), then simulation
>> result is invalid because the rest of warm-up cycles won't be simulated
>> with
>> Opal.
>> 2- if ( N > number of a actual cycles in 2 second run), then simulation
>> will be valid for M cycles where M is the true number of cycles in 2
>> seconds
>> run, and the remaining N-M cycles will be devoted to OS background
>> instruction. But the result is for N cycles which means a summation of 2
>> seconds run and remaining OS background instruction.
>>
>> Am I right?
>>
>> // Naderan *Mahmood;
>>
>>
>>
>> On Tue, Mar 30, 2010 at 1:33 PM, Mahmood Naderan
>> <mahmood.nt@xxxxxxxxx>wrote:
>>
>>> Finay I run barnes workload. One question still present: what is the
>>> difference between cold and warm input. How can one determine a
>>> boundary for cold and warm input?
>>>
>>> On 3/29/10, Dan Gibson <degibson@xxxxxxxx> wrote:
>>> > On Mon, Mar 29, 2010 at 9:29 AM, Mahmood Naderan
>>> > <mahmood.nt@xxxxxxxxx>wrote:
>>> >
>>> >> I did that and then some lines inserted in the file. Then I made
>>> >> another checkpoint but every time I load from the new checkpoint, I
>>> >> saw a message that is:
>>> >>
>>> >>
>>> >>
>>> /***************************************************************************\
>>> >>  > Physical Memory object cannot be found. If you are NOT compiling
>>> Ruby
>>> >> and <
>>> >>  > you see this message, something is wrong.
>>> >>   <
>>> >>  > This message is part of the normal compilation process.
>>> >>   <
>>> >>
>>> >>
>>> >>
>>> \***************************************************************************/
>>> >>
>>> >> I don't know what is he saying. Either it is "normal" or "wrong"?
>>> >>
>>> >
>>> > It is wrong. That message comes from Ruby. You took a checkpoint after
>>> > loading Ruby, therefore, Ruby is part of the .check file. This is bad,
>>> > because ruby is then re-loaded out of order with respect to the
>>> > physical
>>> > memory object -- I.e., Ruby can't find the physical memory, because it
>>> > doesn't exist at ruby load-time.
>>> >
>>> > Solution: Manually edit your .check file and remove all mention of
>>> > Ruby.
>>> > Make a backup before you begin.
>>> >
>>> >
>>> >>
>>> >> I have to say, running a workload is a very complicated task for
>>> >> beginners, with lots of .py file that I don't understand what are the
>>> >> steps to run them in order.
>>> >>
>>> >
>>> > Agreed -- it ain't easy. It turns out, running entire operating systems
>>> in
>>> > simulation is tricky.
>>> >
>>> >
>>> >>
>>> >> Before reading that mailing list thread, I did what is stated in the
>>> >> "Configure Simics for Ruby/Opal" section of the Ubuntu PDF guide.
>>> >> There are some commands that shows the order of laoding the Ruby and
>>> >> Opal. One more question is, by running the command "opal0.sim-step
>>> >> 1000000" which workload is actually running because in the prior steps
>>> >> no workload is selected!
>>> >>
>>> >
>>> > If you don't start a workload on the target os, then you just run
>>> whatever
>>> > background processes the OS wants to schedule (and/or the idle loop).
>>> >
>>> > Regards,
>>> > Dan
>>> >
>>> >
>>> >>
>>> >>
>>> >> On 3/29/10, Dan Gibson <degibson@xxxxxxxx> wrote:
>>> >> > It looks like you never actually ran the simulation, therefore
>>> >> > Ruby's
>>> >> caches
>>> >> > are empty.
>>> >> >
>>> >> > Try inserting this:
>>> >> > simics> c 100
>>> >> > After ruby0.init.
>>> >> >
>>> >> > Regards,
>>> >> > Dan
>>> >> >
>>> >> > On Mon, Mar 29, 2010 at 4:31 AM, Mahmood Naderan
>>> >> > <mahmood.nt@xxxxxxxxx>wrote:
>>> >> >
>>> >> >> I am trying to run the barnes workload based on a disscussion at
>>> >> >>
>>> https://lists.cs.wisc.edu/archive/gems-users/2006-March/msg00143.shtml.
>>> >> >> I ran the ./barnes < input-warm in the taret machine and after the
>>> >> >> run, I made a checkpoint. Then I exited and loaded the checkpoint.
>>> Now
>>> >> >> when I run "ruby0.savecache filename", it says that 0 lines written
>>> >> >> and the file actually has zero size.
>>> >> >>
>>> >> >> mahmood@magma:sarek$ ./simics -stall -c
>>> >> >> ../../../checkpoints/barnes-warm.check
>>> >> >> simics> istc-disable
>>> >> >> Turning I-STC off and flushing old data
>>> >> >> simics> dstc-disable
>>> >> >> Turning D-STC off and flushing old data
>>> >> >> simics> cpu-switch-time 1
>>> >> >> The switch time will change to 1 cycles (for CPU-0) once all
>>> >> >> processors have synchronized.
>>> >> >> simics> load-module ruby
>>> >> >> successful installation of the ruby timing model.
>>> >> >> simics> ruby0.init
>>> >> >> Ruby Timing Mode
>>> >> >> Creating event queue...
>>> >> >> Creating event queue done
>>> >> >> Creating system...
>>> >> >>  Processors: 1
>>> >> >> Creating system done
>>> >> >> Ruby initialization complete
>>> >> >> simics> ruby0.save-caches barnes.cache.gz
>>> >> >> Writing cache contents to 'barnes.cache.gz'...done. (0 cache lines
>>> >> >> written)
>>> >> >> simics>
>>> >> >>
>>> >> >> Where did I make a mistake?
>>> >> >>
>>> >> >> --
>>> >> >> // Naderan *Mahmood;
>>> >> >> _______________________________________________
>>> >> >> 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 <http://www.cs.wisc.edu/%7Egibson>
>>> >> > <http://www.cs.wisc.edu/%7Egibson>[esc]:wq!
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> // Naderan *Mahmood;
>>> >> _______________________________________________
>>> >> 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
>>> > <http://www.cs.wisc.edu/%7Egibson>[esc]:wq!
>>> >
>>>
>>>
>>> --
>>> // Naderan *Mahmood;
>>>
>>
>>
>> _______________________________________________
>> 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!
>


-- 
// Naderan *Mahmood;
[← Prev in Thread] Current Thread [Next in Thread→]