Hi Korey,
The workloads seem to be getting setup correctly. I compared the trace with
those in:
1. w/o SMT in inorder
2. w/ SMT in o3
The excerpt from the trace file in inorder:
0: system.cpu: Workload[0] process is 0
0: system.cpu: Workload[1] process is 0
matches with that in o3.
I could not find anything called a process flag in trace, but I can follow
your advice about using the DPRINTF debug statements, if need be.
In the inorder trace file, I don't see a message like this:
0: system.cpu: Adding Thread 0 to active threads list in CPU.
for thread 1.
For example, in the O3 trace file, I could locate debug messages pertaining
to activation of both threads 0 and 1 during simulation:
...
0: global: Calling activate on Thread Context 0
0: system.cpu: [tid:0]: Calling activate thread.
0: system.cpu: [tid:0]: Adding to active threads list
...
...
0: global: Calling activate on Thread Context 1
0: system.cpu: [tid:1]: Calling activate thread.
0: system.cpu: [tid:1]: Adding to active threads list
...
I have another point of concern (perhaps a bit digressive):
On inspecting the trace file for the single workload scenario, I noticed
that event messages are being dumped every 500 ticks (for 2 GHz clock) even
if there is nothing to be done. There is absolutely no difference in those
messages which indicate that there's nothing to be done. I am not sure if I
am conveying what I mean to or not but do let me know if you think. It
appears that bogus events are being generated which makes the simulation
engine evaluate every clock cycle. In O3, I can see that the ticks jump from
16000 to 49000 without any events in between. I'd expect something like that
in inorder too. Please correct me if I am wrong.
regards,
Soumyaroop.
On Wed, Aug 19, 2009 at 5:57 PM, Korey Sewell <[email protected]> wrote:
>
> Could you give me any pointers to debug this?
>
> Sure ... Thanks for your interest...
>
> I think the problem is that right now the model is hardcoded for 1 thread
> in some places. The resources for the model are specified in
> "pipeline_traits.cc" and then I believe workloads are registered somewhere
> in "cpu.cc" and/or "*_cpu_builder.cc".
>
> To debug, I would be more interested in what's happening on cycle 0. Are
> the workloads even getting setup correctly? There may be another flag that
> you can turn on (Process?) ... Compare the output you are getting w/out SMT
> in inorder and w/SMT for inorder. Do you see the workload getting setup in
> one of those? If not, I would add my own DPRINTF debug messages to the
> aforementioned files.
>
> Once you've verified the workloads are being loaded, then the next question
> is why aren't the threads being fetched from? Check "first_stage.cc" in that
> case... I would guess the threads arent being added to the activeThreads
> list correctly maybe.
>
> If you are willing to help debug and commit changes, we'd more than
> appreciate it. Personally, I've got my hands full with getting around to O3
> SMT stuff but help would be much appreciated on inorder. I'm going to dig up
> and send you some of the hardcoded SMT stuff I have for inorder to help you
> along the way as well...
>
>
>
> --
> - Korey
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
--
Soumyaroop Roy
Ph.D. Candidate
Department of Computer Science and Engineering
University of South Florida, Tampa
http://www.csee.usf.edu/~sroy
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
