Discussion:
[gem5-dev] Review Request: sim: simulate with multiple event queues
Nilay Vaish
2013-01-25 11:43:06 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

Review request for Default.


Description
-------

Changeset 9486:a6a90f478e1d
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
It was tested with ruby_network_test.py with this patch.

Note: The testing was carried out making sure that different components
do not send any messages to each other. This means that we still lack
the ability to communicate using message buffers or ports. But other
things like simulation start and end, synchronizing after every quantum
seem to be working.

While the patch itself is not definitive, but I thought it would be best
to get it reviewed before adding more code.


Diffs
-----

src/cpu/base.cc b0fa6b872f40
src/dev/etherlink.cc b0fa6b872f40
src/python/m5/SimObject.py b0fa6b872f40
src/python/m5/event.py b0fa6b872f40
src/python/m5/main.py b0fa6b872f40
src/python/swig/core.i b0fa6b872f40
src/python/swig/event.i b0fa6b872f40
src/sim/SConscript b0fa6b872f40
src/sim/core.hh b0fa6b872f40
src/sim/debug.cc b0fa6b872f40
src/sim/eventq.hh b0fa6b872f40
src/sim/eventq.cc b0fa6b872f40
src/sim/eventq_impl.hh b0fa6b872f40
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc b0fa6b872f40
src/sim/sim_events.hh b0fa6b872f40
src/sim/sim_events.cc b0fa6b872f40
src/sim/sim_exit.hh b0fa6b872f40
src/sim/sim_object.cc b0fa6b872f40
src/sim/simulate.hh b0fa6b872f40
src/sim/simulate.cc b0fa6b872f40
src/sim/stat_control.cc b0fa6b872f40

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Nilay Vaish
2013-02-10 21:44:25 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Feb. 10, 2013, 1:44 p.m.)


Review request for Default.


Description (updated)
-------

Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Steve Reinhardt
2013-02-11 04:19:04 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4013
-----------------------------------------------------------


Hi Nilay,

Thanks a lot for posting this. I'm really excited to see you pushing this forward.

One high-level thought... now that I've looked at this code again after not having seen it for over a year, the repetition of "mainEventQueue" in getMainEventQueue(), curMainEventQueue(), etc. seems really verbose. It made some sense when there was one main event queue, but I'd be in favor of just dropping "Main" basically everywhere it appears. If we need to distinguish the PC-based event queues, we should do it by giving them longer and more distinguished names, and not burden the common case usage. I know this was my naming and not yours... sorry about the extra burden.

Also, I had added "Copyright (c) 2011 Advanced Micro Devices, Inc." to eventq.{cc,hh} and simulate.cc, and it looks like those got dropped somehow... please put them back.


src/sim/core.hh
<http://reviews.gem5.org/r/1667/#comment3865>

This should eventually become a parameter on the Root SimObject, right?



src/sim/debug.cc
<http://reviews.gem5.org/r/1667/#comment3864>

I'm not sure we need this warning... we are dumping all the event queues, right? (Except for the ones that aren't really event queues, like the PC-based ones.)



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment3871>

I would really like to solve this problem without adding yet another field to the Event structure. I think that all the common cases could be solved definitively just by appropriate selection of priorities. I'm surprised that less common cases (if any) don't sort themselves out naturally just because all the threads would be inserting the global events in the same program order.



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment3866>

Do we still need this? The Event flag doesn't seem to be referenced anywhere anymore, and I think the problem it originally addressed (having exit events on PC-based queues) could be addressed much more elegantly by marking the events on the PC-based queues as special anyway.



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment3867>

It would be nice to have this in the constructor, even if it means having a separate derived class for "real" event queues as opposed to PC-based queues.



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment3868>

I know this is my code and not yours, but looking at it now, I'm not sure why I didn't use a std::vector and get rid of the static limit. Does that make initialization too hard?



src/sim/global_event.cc
<http://reviews.gem5.org/r/1667/#comment3869>

This curEventQueue() swapping around is a little funky... how do we know this code is not being called when the other threads are active? It looks like this is replacing my old "inParallelMode" flag... that was not necessarily the best solution either, but at least the intent was clearer, in my opinion. Was there something about that that wasn't working?



src/sim/simulate.cc
<http://reviews.gem5.org/r/1667/#comment3863>

Is there a reason you're now creating all the threads every time simulate() is called, instead of just the first time (as in my previous code)? That seems like a lot of overhead if you're periodically going back to python to do things like dump stats.



src/sim/stat_control.cc
<http://reviews.gem5.org/r/1667/#comment3870>

Are you adding simQuantum here to make sure that this is after the next sync? In the long run it's probably preferable to do this only when necessary, and print a warning when doing so.


- Steve Reinhardt
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-11 14:22:35 UTC
Permalink
Post by Nilay Vaish
Post by Steve Reinhardt
Hi Nilay,
Thanks a lot for posting this. I'm really excited to see you pushing this forward.
One high-level thought... now that I've looked at this code again after not having seen it for over a year, the repetition of "mainEventQueue" in getMainEventQueue(), curMainEventQueue(), etc. seems really verbose. It made some sense when there was one main event queue, but I'd be in favor of just dropping "Main" basically everywhere it appears. If we need to distinguish the PC-based event queues, we should do it by giving them longer and more distinguished names, and not burden the common case usage. I know this was my naming and not yours... sorry about the extra burden.
Also, I had added "Copyright (c) 2011 Advanced Micro Devices, Inc." to eventq.{cc,hh} and simulate.cc, and it looks like those got dropped somehow... please put them back.
I'll take care of these comments.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/stat_control.cc, line 253
<http://reviews.gem5.org/r/1667/diff/2/?file=33951#file33951line253>
Are you adding simQuantum here to make sure that this is after the next sync? In the long run it's probably preferable to do this only when necessary, and print a warning when doing so.
Yes.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/simulate.cc, line 87
<http://reviews.gem5.org/r/1667/diff/2/?file=33950#file33950line87>
Is there a reason you're now creating all the threads every time simulate() is called, instead of just the first time (as in my previous code)? That seems like a lot of overhead if you're periodically going back to python to do things like dump stats.
In the previous code, threads (other than the main thread) would not exit
after the simulation. While you might want to say that they would eventually
exit when the process gets done, I am not happy with that either.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/global_event.cc, line 70
<http://reviews.gem5.org/r/1667/diff/2/?file=33943#file33943line70>
This curEventQueue() swapping around is a little funky... how do we know this code is not being called when the other threads are active? It looks like this is replacing my old "inParallelMode" flag... that was not necessarily the best solution either, but at least the intent was clearer, in my opinion. Was there something about that that wasn't working?
I am unable to recall as to why I removed the inParallelMode flag.
I'll put it back.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.cc, line 57
<http://reviews.gem5.org/r/1667/diff/2/?file=33940#file33940line57>
I know this is my code and not yours, but looking at it now, I'm not sure why I didn't use a std::vector and get rid of the static limit. Does that make initialization too hard?
I'll try to see if it is possible. There are certain initialization
issues. I think I have better understanding of the code than
before, so I might be able to come with better solutions.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.hh, line 498
<http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line498>
It would be nice to have this in the constructor, even if it means having a separate derived class for "real" event queues as opposed to PC-based queues.
I wanted to have it in the constructor. But I am facing this peculiar issue.
When I move this very line of code in the constructor, the memory gets
allocated. But later on, the async_queue_mutex pointer somehow gets set to NULL.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.hh, line 470
<http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line470>
Do we still need this? The Event flag doesn't seem to be referenced anywhere anymore, and I think the problem it originally addressed (having exit events on PC-based queues) could be addressed much more elegantly by marking the events on the PC-based queues as special anyway.
I'll remove it.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.hh, line 198
<http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line198>
I would really like to solve this problem without adding yet another field to the Event structure. I think that all the common cases could be solved definitively just by appropriate selection of priorities. I'm surprised that less common cases (if any) don't sort themselves out naturally just because all the threads would be inserting the global events in the same program order.
Let me give an example here. Suppose two threads need to insert global exit
events in the next quantum at the same cycle. They will insert the event in
their own queues and the async queue of the other thread. When each thread
will make insertions from its async queue to its actual event queue, the
event ordering would be opposite in the two threads, unless there is a global
order between the events. When the threads execute these events, they end up
on different barriers and the simulation is not able to proceed ahead.

I think we do need a total order amongst global events. If you have some other
solution in mind, I am ready to consider it.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/debug.cc, line 106
<http://reviews.gem5.org/r/1667/diff/2/?file=33938#file33938line106>
I'm not sure we need this warning... we are dumping all the event queues, right? (Except for the ones that aren't really event queues, like the PC-based ones.)
Removed!
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/core.hh, line 49
<http://reviews.gem5.org/r/1667/diff/2/?file=33937#file33937line49>
This should eventually become a parameter on the Root SimObject, right?
Yes.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4013
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-02-11 16:40:09 UTC
Permalink
Post by Nilay Vaish
Post by Steve Reinhardt
Hi Nilay,
Thanks a lot for posting this. I'm really excited to see you pushing this forward.
One high-level thought... now that I've looked at this code again after not having seen it for over a year, the repetition of "mainEventQueue" in getMainEventQueue(), curMainEventQueue(), etc. seems really verbose. It made some sense when there was one main event queue, but I'd be in favor of just dropping "Main" basically everywhere it appears. If we need to distinguish the PC-based event queues, we should do it by giving them longer and more distinguished names, and not burden the common case usage. I know this was my naming and not yours... sorry about the extra burden.
Also, I had added "Copyright (c) 2011 Advanced Micro Devices, Inc." to eventq.{cc,hh} and simulate.cc, and it looks like those got dropped somehow... please put them back.
I'll take care of these comments.
Thanks!
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.cc, line 57
<http://reviews.gem5.org/r/1667/diff/2/?file=33940#file33940line57>
I know this is my code and not yours, but looking at it now, I'm not sure why I didn't use a std::vector and get rid of the static limit. Does that make initialization too hard?
I'll try to see if it is possible. There are certain initialization
issues. I think I have better understanding of the code than
before, so I might be able to come with better solutions.
Maybe a different approach to event queue initialization would solve the problem with your mutex pointer as well.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/simulate.cc, line 87
<http://reviews.gem5.org/r/1667/diff/2/?file=33950#file33950line87>
Is there a reason you're now creating all the threads every time simulate() is called, instead of just the first time (as in my previous code)? That seems like a lot of overhead if you're periodically going back to python to do things like dump stats.
In the previous code, threads (other than the main thread) would not exit
after the simulation. While you might want to say that they would eventually
exit when the process gets done, I am not happy with that either.
Is there something that happens on thread destruction that we care about? I agree that it would be more elegant to proactively kill the threads rather than let them get killed when the process ends, but I don't think that abstract elegance justifies the cost of having to recreate them every time we call simulate().

Unless there's a practical reason why it matters that we explicitly kill the threads, I can tolerate the inelegance of it happening implicitly.
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.hh, line 198
<http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line198>
I would really like to solve this problem without adding yet another field to the Event structure. I think that all the common cases could be solved definitively just by appropriate selection of priorities. I'm surprised that less common cases (if any) don't sort themselves out naturally just because all the threads would be inserting the global events in the same program order.
Let me give an example here. Suppose two threads need to insert global exit
events in the next quantum at the same cycle. They will insert the event in
their own queues and the async queue of the other thread. When each thread
will make insertions from its async queue to its actual event queue, the
event ordering would be opposite in the two threads, unless there is a global
order between the events. When the threads execute these events, they end up
on different barriers and the simulation is not able to proceed ahead.
I think we do need a total order amongst global events. If you have some other
solution in mind, I am ready to consider it.
I understand the need for a consistent order to prevent deadlocks. Thanks for the example of how this arises in practice.

Given that global events must always be scheduled at least one quantum away, what if we require that global events (including all their local subevents) must be scheduled when we're in "serial mode" during the quantum synchronization? There could be an additional locked async queue for global events that gets drained at the quantum synchronization, and all global events go through this queue. How does that sound?


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4013
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-13 19:48:00 UTC
Permalink
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.hh, line 198
<http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line198>
I would really like to solve this problem without adding yet another field to the Event structure. I think that all the common cases could be solved definitively just by appropriate selection of priorities. I'm surprised that less common cases (if any) don't sort themselves out naturally just because all the threads would be inserting the global events in the same program order.
Let me give an example here. Suppose two threads need to insert global exit
events in the next quantum at the same cycle. They will insert the event in
their own queues and the async queue of the other thread. When each thread
will make insertions from its async queue to its actual event queue, the
event ordering would be opposite in the two threads, unless there is a global
order between the events. When the threads execute these events, they end up
on different barriers and the simulation is not able to proceed ahead.
I think we do need a total order amongst global events. If you have some other
solution in mind, I am ready to consider it.
I understand the need for a consistent order to prevent deadlocks. Thanks for the example of how this arises in practice.
Given that global events must always be scheduled at least one quantum away, what if we require that global events (including all their local subevents) must be scheduled when we're in "serial mode" during the quantum synchronization? There could be an additional locked async queue for global events that gets drained at the quantum synchronization, and all global events go through this queue. How does that sound?
Here is a different strategy. Have a global mutex that a thread needs
to hold inorder to schedule global events. Add the global events to
the asyncq first.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4013
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-02-13 20:44:14 UTC
Permalink
Post by Nilay Vaish
Post by Steve Reinhardt
src/sim/eventq.hh, line 198
<http://reviews.gem5.org/r/1667/diff/2/?file=33939#file33939line198>
I would really like to solve this problem without adding yet another field to the Event structure. I think that all the common cases could be solved definitively just by appropriate selection of priorities. I'm surprised that less common cases (if any) don't sort themselves out naturally just because all the threads would be inserting the global events in the same program order.
Let me give an example here. Suppose two threads need to insert global exit
events in the next quantum at the same cycle. They will insert the event in
their own queues and the async queue of the other thread. When each thread
will make insertions from its async queue to its actual event queue, the
event ordering would be opposite in the two threads, unless there is a global
order between the events. When the threads execute these events, they end up
on different barriers and the simulation is not able to proceed ahead.
I think we do need a total order amongst global events. If you have some other
solution in mind, I am ready to consider it.
I understand the need for a consistent order to prevent deadlocks. Thanks for the example of how this arises in practice.
Given that global events must always be scheduled at least one quantum away, what if we require that global events (including all their local subevents) must be scheduled when we're in "serial mode" during the quantum synchronization? There could be an additional locked async queue for global events that gets drained at the quantum synchronization, and all global events go through this queue. How does that sound?
Here is a different strategy. Have a global mutex that a thread needs
to hold inorder to schedule global events. Add the global events to
the asyncq first.
If you mean that global events are added via the async queue even on the local thread, then I think yes, that strategy would also work. I assume that global events (other than the recurring sync event) are scheduled rarely enough that we should target the simplest solution that works; I'll let you decide what is simplest here.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4013
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-02-11 18:25:42 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4011
-----------------------------------------------------------


Hi Nilay,

Thanks for all of this, it's really great to see us making some progress here. A concern I have is with the use of __thread and how that effects clang whose static analysis tool has found quite a few bugs for us recently and OS X which doesn't support TLS (at least until something on OS X implements C++11 thread local support). So, I think we need to come up with some strategy to deal with this as quite a few people use OS x as their primary development machine for gem5 and I don't think we want to weld ourselves to gcc since llvm/clang does have some good points.

Thanks,
Ali





src/python/m5/SimObject.py
<http://reviews.gem5.org/r/1667/#comment3859>

How does this work? I'm not saying it doesn't I just don't understand what the proxy is doing in this case? Looking for any object that is a UInt32? Do we want to have an specific EventQueueId object?



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment3860>

I'm a bit concerned with using __thread since it isn't supported on OS X as far as I know. I'd be fine for requiring TLS on a platform that we're using multi-threading, but if we're going to go down that route we need to ifdef it such that single threaded simulation doesn't use it. The other way would be to make _tls-mainEventQueue a #define and have a TLS or pthread_getspecfific()/setspecific() version.


- Ali Saidi
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-02-11 19:21:42 UTC
Permalink
Post by Nilay Vaish
src/python/m5/SimObject.py, line 604
<http://reviews.gem5.org/r/1667/diff/2/?file=33931#file33931line604>
How does this work? I'm not saying it doesn't I just don't understand what the proxy is doing in this case? Looking for any object that is a UInt32? Do we want to have an specific EventQueueId object?
Good catch, that should probably be Parent.eventq_index, not Parent.any. We probably also need to explicitly set Root.eventq_index to 0 somewhere. As far as how it works now, it's probably totally an accident...


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4011
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-13 18:39:34 UTC
Permalink
Post by Steve Reinhardt
src/python/m5/SimObject.py, line 604
<http://reviews.gem5.org/r/1667/diff/2/?file=33931#file33931line604>
How does this work? I'm not saying it doesn't I just don't understand what the proxy is doing in this case? Looking for any object that is a UInt32? Do we want to have an specific EventQueueId object?
Good catch, that should probably be Parent.eventq_index, not Parent.any. We probably also need to explicitly set Root.eventq_index to 0 somewhere. As far as how it works now, it's probably totally an accident...
I have changed the code as per the suggestion made. Can anyone explain
what Parent.any does? I used to think that some Python code probes the
parent of the object for the correct value that should be assigned to
variable that was assigned Parent.any in a params file.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4011
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-02-13 18:50:12 UTC
Permalink
See http://gem5.org/Simulation_Scripts_Explained#Relative_references for
the official explanation.

Parent.any just looks for a type match and not a parameter name match.
It's generally used where you're looking to find an "enclosing" object
further up the hierarchy (like a System object) and not just inheriting a
parameter setting.

That said, we probably do abuse it some, in that there are likely places
where we could use a "normal" Parent proxy and not Parent.any and it would
be clearer.

Steve
Post by Nilay Vaish
http://reviews.gem5.org/r/1667/
src/python/m5/SimObject.py<http://reviews.gem5.org/r/1667/diff/2/?file=33931#file33931line604> (Diff
revision 2)
596
cxx_header = "sim/sim_object.hh"
597
eventq_index = Param.UInt32(Parent.any, "Event Queue Index")
How does this work? I'm not saying it doesn't I just don't understand what the proxy is doing in this case? Looking for any object that is a UInt32? Do we want to have an specific EventQueueId object?
Good catch, that should probably be Parent.eventq_index, not Parent.any. We probably also need to explicitly set Root.eventq_index to 0 somewhere. As far as how it works now, it's probably totally an accident...
I have changed the code as per the suggestion made. Can anyone explain
what Parent.any does? I used to think that some Python code probes the
parent of the object for the correct value that should be assigned to
variable that was assigned Parent.any in a params file.
- Nilay
Review request for Default.
By Nilay Vaish.
*Updated Feb. 10, 2013, 1:44 p.m.*
Description
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
- src/cpu/base.cc (ff4b1bde5f60)
- src/dev/etherlink.cc (ff4b1bde5f60)
- src/python/m5/SimObject.py (ff4b1bde5f60)
- src/python/m5/event.py (ff4b1bde5f60)
- src/python/m5/main.py (ff4b1bde5f60)
- src/python/swig/core.i (ff4b1bde5f60)
- src/python/swig/event.i (ff4b1bde5f60)
- src/sim/SConscript (ff4b1bde5f60)
- src/sim/core.hh (ff4b1bde5f60)
- src/sim/debug.cc (ff4b1bde5f60)
- src/sim/eventq.hh (ff4b1bde5f60)
- src/sim/eventq.cc (ff4b1bde5f60)
- src/sim/eventq_impl.hh (ff4b1bde5f60)
- src/sim/global_event.hh (PRE-CREATION)
- src/sim/global_event.cc (PRE-CREATION)
- src/sim/serialize.cc (ff4b1bde5f60)
- src/sim/sim_events.hh (ff4b1bde5f60)
- src/sim/sim_events.cc (ff4b1bde5f60)
- src/sim/sim_exit.hh (ff4b1bde5f60)
- src/sim/sim_object.cc (ff4b1bde5f60)
- src/sim/simulate.hh (ff4b1bde5f60)
- src/sim/simulate.cc (ff4b1bde5f60)
- src/sim/stat_control.cc (ff4b1bde5f60)
View Diff <http://reviews.gem5.org/r/1667/diff/>
Ali Saidi
2013-02-13 18:45:58 UTC
Permalink
Post by Steve Reinhardt
src/python/m5/SimObject.py, line 604
<http://reviews.gem5.org/r/1667/diff/2/?file=33931#file33931line604>
How does this work? I'm not saying it doesn't I just don't understand what the proxy is doing in this case? Looking for any object that is a UInt32? Do we want to have an specific EventQueueId object?
Good catch, that should probably be Parent.eventq_index, not Parent.any. We probably also need to explicitly set Root.eventq_index to 0 somewhere. As far as how it works now, it's probably totally an accident...
I have changed the code as per the suggestion made. Can anyone explain
what Parent.any does? I used to think that some Python code probes the
parent of the object for the correct value that should be assigned to
variable that was assigned Parent.any in a params file.
Hi Nilay,

Parent.any says traverse the object hierarchy and find me a parameter to that fits my type. In the case of Param.System(Parent.any) This is an easy way to get a pointer to a system object. In this case I suppose it went looking for an parent object that had a parameter that was a UInt32. It sorta worked because we don't have many parameters of type Uint32, but it could get the wrong value for sure.


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4011
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-13 18:53:14 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq.cc, line 59
<http://reviews.gem5.org/r/1667/diff/2/?file=33940#file33940line59>
I'm a bit concerned with using __thread since it isn't supported on OS X as far as I know. I'd be fine for requiring TLS on a platform that we're using multi-threading, but if we're going to go down that route we need to ifdef it such that single threaded simulation doesn't use it. The other way would be to make _tls-mainEventQueue a #define and have a TLS or pthread_getspecfific()/setspecific() version.
So what would happen on OS X when one compiles a code with some variable preceeded
with __thread? Will GCC / Clang / any other compiler fail to compile the code? Or
will they output an executeable that does not have a tls section, hence will run
correctly only for a single threaded simulation?

If it is the latter, then we may just want to explicitly state it some where that
multi-threading is only supported on Linux as of now.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4011
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-02-13 21:13:55 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq.cc, line 59
<http://reviews.gem5.org/r/1667/diff/2/?file=33940#file33940line59>
I'm a bit concerned with using __thread since it isn't supported on OS X as far as I know. I'd be fine for requiring TLS on a platform that we're using multi-threading, but if we're going to go down that route we need to ifdef it such that single threaded simulation doesn't use it. The other way would be to make _tls-mainEventQueue a #define and have a TLS or pthread_getspecfific()/setspecific() version.
So what would happen on OS X when one compiles a code with some variable preceeded
with __thread? Will GCC / Clang / any other compiler fail to compile the code? Or
will they output an executeable that does not have a tls section, hence will run
correctly only for a single threaded simulation?
If it is the latter, then we may just want to explicitly state it some where that
multi-threading is only supported on Linux as of now.
Unfortunately to say the issue is complex doesn't really do it justice. I've tried all this on OS X 10.8 with the developer tools installed.

I started with the following:
#include <thread>
#include <iostream>

using namespace std;

__thread int foo;

void test()
{
foo = 1;
cout << "foo = " << foo << endl;
return;
}

int main(int argc, char **argv)
{

thread t1(test);
thread t2(test);
t1.join();
t2.join();
return 0;
}


g++: error: thread-local storage not supported for this target
g++-fsf-4.6: doesn't seem to implement std::thread in the c++ library
clang++: no thread
clang++ w/libc++: compiles, but libc++ is a much stricter implementation of the c++ library and enabling it creates all manner of warnings with gem5

If I remove the need for std::thread, use pthreads threads and just have a TLS variable:
g++: error: thread-local storage not supported for this target
g++-fsf-4.6: works
clang++: works
clang++ w/libc++: works

So it seems that the issue isn't as much TLS at this point on OS X. Only the g++ version that ships with the developer tools complains.

Apparently g++4.7 on OS X will let you use std::thread.
http://solarianprogrammer.com/2012/02/20/living-on-the-edge-building-gcc-4-7-on-mac-osx-lion/

sigh...


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4011
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 10, 2013, 1:44 p.m.)
Review request for Default.
Description
-------
Changeset 9497:484d33f78ef4
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc ff4b1bde5f60
src/dev/etherlink.cc ff4b1bde5f60
src/python/m5/SimObject.py ff4b1bde5f60
src/python/m5/event.py ff4b1bde5f60
src/python/m5/main.py ff4b1bde5f60
src/python/swig/core.i ff4b1bde5f60
src/python/swig/event.i ff4b1bde5f60
src/sim/SConscript ff4b1bde5f60
src/sim/core.hh ff4b1bde5f60
src/sim/debug.cc ff4b1bde5f60
src/sim/eventq.hh ff4b1bde5f60
src/sim/eventq.cc ff4b1bde5f60
src/sim/eventq_impl.hh ff4b1bde5f60
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/serialize.cc ff4b1bde5f60
src/sim/sim_events.hh ff4b1bde5f60
src/sim/sim_events.cc ff4b1bde5f60
src/sim/sim_exit.hh ff4b1bde5f60
src/sim/sim_object.cc ff4b1bde5f60
src/sim/simulate.hh ff4b1bde5f60
src/sim/simulate.cc ff4b1bde5f60
src/sim/stat_control.cc ff4b1bde5f60
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-14 15:29:45 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Feb. 14, 2013, 7:29 a.m.)


Review request for Default.


Description (updated)
-------

Changeset 9512:6341f983f1cd
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/cpu/base.cc 921d858c5bc7
src/dev/etherlink.cc 921d858c5bc7
src/python/m5/SimObject.py 921d858c5bc7
src/python/m5/event.py 921d858c5bc7
src/python/m5/main.py 921d858c5bc7
src/python/m5/simulate.py 921d858c5bc7
src/python/swig/core.i 921d858c5bc7
src/python/swig/event.i 921d858c5bc7
src/sim/Root.py 921d858c5bc7
src/sim/SConscript 921d858c5bc7
src/sim/core.hh 921d858c5bc7
src/sim/debug.cc 921d858c5bc7
src/sim/eventq.hh 921d858c5bc7
src/sim/eventq.cc 921d858c5bc7
src/sim/eventq_impl.hh 921d858c5bc7
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 921d858c5bc7
src/sim/serialize.cc 921d858c5bc7
src/sim/sim_events.hh 921d858c5bc7
src/sim/sim_events.cc 921d858c5bc7
src/sim/sim_exit.hh 921d858c5bc7
src/sim/sim_object.cc 921d858c5bc7
src/sim/simulate.hh 921d858c5bc7
src/sim/simulate.cc 921d858c5bc7
src/sim/stat_control.cc 921d858c5bc7

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Steve Reinhardt
2013-02-14 17:04:22 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4037
-----------------------------------------------------------


Nice! Thanks for the changes, Nilay. This is really looking good. My comments are pretty minor.



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment3907>

You can use csprintf() to generate a string directly, e.g.:

string s = csprintf(sp, "MainEventQueue-%d", index);
mainEventQueue.push_back(new EventQueue(s));



src/sim/eventq_impl.hh
<http://reviews.gem5.org/r/1667/#comment3913>

I would put a small comment here referring to the larger comment at BaseGlobalEvent::schedule() to explain why global events need to be put on the async queue even for the current thread.



src/sim/global_event.hh
<http://reviews.gem5.org/r/1667/#comment3911>

This comment needs to be updated.



src/sim/global_event.cc
<http://reviews.gem5.org/r/1667/#comment3912>

There should be a comment here explaining the situation about global events and why we need a lock and why they have to be scheduled on the async queue to guarantee a consistent global order to avoid deadlock.



src/sim/simulate.cc
<http://reviews.gem5.org/r/1667/#comment3910>

typo in comment



src/python/m5/simulate.py
<http://reviews.gem5.org/r/1667/#comment3908>

I don't think we need two different variables that both have the same purpose of doing something only the first time simulate() is called... or is there something else going on here?



src/python/m5/simulate.py
<http://reviews.gem5.org/r/1667/#comment3914>

Is there ever a case where we register an atexit callback and we want to make sure it's invoked even if the python script never calls simulate()? Practically speaking, I doubt it, but I thought I'd bring it up since clearly this change would break that assumption.



src/sim/Root.py
<http://reviews.gem5.org/r/1667/#comment3909>

I'd prefer to make the default 0, which would make it clear that we shouldn't schedule a quantum, then require anyone using multiple threads to specify a quantum explicitly (and error out if they don't).


- Steve Reinhardt
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 14, 2013, 7:29 a.m.)
Review request for Default.
Description
-------
Changeset 9512:6341f983f1cd
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc 921d858c5bc7
src/dev/etherlink.cc 921d858c5bc7
src/python/m5/SimObject.py 921d858c5bc7
src/python/m5/event.py 921d858c5bc7
src/python/m5/main.py 921d858c5bc7
src/python/m5/simulate.py 921d858c5bc7
src/python/swig/core.i 921d858c5bc7
src/python/swig/event.i 921d858c5bc7
src/sim/Root.py 921d858c5bc7
src/sim/SConscript 921d858c5bc7
src/sim/core.hh 921d858c5bc7
src/sim/debug.cc 921d858c5bc7
src/sim/eventq.hh 921d858c5bc7
src/sim/eventq.cc 921d858c5bc7
src/sim/eventq_impl.hh 921d858c5bc7
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 921d858c5bc7
src/sim/serialize.cc 921d858c5bc7
src/sim/sim_events.hh 921d858c5bc7
src/sim/sim_events.cc 921d858c5bc7
src/sim/sim_exit.hh 921d858c5bc7
src/sim/sim_object.cc 921d858c5bc7
src/sim/simulate.hh 921d858c5bc7
src/sim/simulate.cc 921d858c5bc7
src/sim/stat_control.cc 921d858c5bc7
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-14 18:12:16 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Feb. 14, 2013, 10:12 a.m.)


Review request for Default.


Description (updated)
-------

Changeset 9513:32bd5af91270
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/cpu/base.cc 615456167b9d
src/dev/etherlink.cc 615456167b9d
src/python/m5/SimObject.py 615456167b9d
src/python/m5/event.py 615456167b9d
src/python/m5/main.py 615456167b9d
src/python/m5/simulate.py 615456167b9d
src/python/swig/core.i 615456167b9d
src/python/swig/event.i 615456167b9d
src/sim/Root.py 615456167b9d
src/sim/SConscript 615456167b9d
src/sim/core.hh 615456167b9d
src/sim/debug.cc 615456167b9d
src/sim/eventq.hh 615456167b9d
src/sim/eventq.cc 615456167b9d
src/sim/eventq_impl.hh 615456167b9d
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 615456167b9d
src/sim/serialize.cc 615456167b9d
src/sim/sim_events.hh 615456167b9d
src/sim/sim_events.cc 615456167b9d
src/sim/sim_exit.hh 615456167b9d
src/sim/sim_object.cc 615456167b9d
src/sim/simulate.hh 615456167b9d
src/sim/simulate.cc 615456167b9d
src/sim/stat_control.cc 615456167b9d

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Nilay Vaish
2013-02-14 18:17:36 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Feb. 14, 2013, 10:17 a.m.)


Review request for Default.


Description (updated)
-------

Changeset 9513:93fc3141ee79
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/cpu/base.cc 615456167b9d
src/dev/etherlink.cc 615456167b9d
src/python/m5/SimObject.py 615456167b9d
src/python/m5/event.py 615456167b9d
src/python/m5/main.py 615456167b9d
src/python/m5/simulate.py 615456167b9d
src/python/swig/core.i 615456167b9d
src/python/swig/event.i 615456167b9d
src/sim/Root.py 615456167b9d
src/sim/SConscript 615456167b9d
src/sim/core.hh 615456167b9d
src/sim/debug.cc 615456167b9d
src/sim/eventq.hh 615456167b9d
src/sim/eventq.cc 615456167b9d
src/sim/eventq_impl.hh 615456167b9d
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 615456167b9d
src/sim/serialize.cc 615456167b9d
src/sim/sim_events.hh 615456167b9d
src/sim/sim_events.cc 615456167b9d
src/sim/sim_exit.hh 615456167b9d
src/sim/sim_object.cc 615456167b9d
src/sim/simulate.hh 615456167b9d
src/sim/simulate.cc 615456167b9d
src/sim/stat_control.cc 615456167b9d

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Ali Saidi
2013-02-14 18:23:40 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4038
-----------------------------------------------------------


Hi Nilay,

Could you see if you can easily #ifdef the __thread commands and the creation of threads such that if the platform doesn't support one or both features we can still compile and run?

Thanks,
Ali


- Ali Saidi
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 14, 2013, 10:17 a.m.)
Review request for Default.
Description
-------
Changeset 9513:93fc3141ee79
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc 615456167b9d
src/dev/etherlink.cc 615456167b9d
src/python/m5/SimObject.py 615456167b9d
src/python/m5/event.py 615456167b9d
src/python/m5/main.py 615456167b9d
src/python/m5/simulate.py 615456167b9d
src/python/swig/core.i 615456167b9d
src/python/swig/event.i 615456167b9d
src/sim/Root.py 615456167b9d
src/sim/SConscript 615456167b9d
src/sim/core.hh 615456167b9d
src/sim/debug.cc 615456167b9d
src/sim/eventq.hh 615456167b9d
src/sim/eventq.cc 615456167b9d
src/sim/eventq_impl.hh 615456167b9d
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 615456167b9d
src/sim/serialize.cc 615456167b9d
src/sim/sim_events.hh 615456167b9d
src/sim/sim_events.cc 615456167b9d
src/sim/sim_exit.hh 615456167b9d
src/sim/sim_object.cc 615456167b9d
src/sim/simulate.hh 615456167b9d
src/sim/simulate.cc 615456167b9d
src/sim/stat_control.cc 615456167b9d
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay
2013-02-14 18:41:10 UTC
Permalink
Post by Steve Reinhardt
Hi Nilay,
Could you see if you can easily #ifdef the __thread commands and the
creation of threads such that if the platform doesn't support one or both
features we can still compile and run?
I'll borrow an OS X laptop and see what parts need to be protected.

--
Nilay
Ali Saidi
2013-02-14 18:58:42 UTC
Permalink
Thanks Nilay,

I still haven't groked all your code completely ,but
it seems like perhaps having a #define for TLS_VARIABLE and setting it
to nothing if tls isn't supported and just #ifdefing the control flow
through simulate() might be sufficient to get the job done.

Thanks
again,

Ali
Post by Nilay
Hi Nilay, Could
you see if you can easily #ifdef the __thread commands and the creation
of threads such that if the platform doesn't support one or both
features we can still compile and run?
Post by Nilay
I'll borrow an OS X laptop
and see what parts need to be protected.
Post by Nilay
--
Nilay
_______________________________________________
Post by Nilay
gem5-dev mailing
list
Post by Nilay
http://m5sim.org/mailman/listinfo/gem5-dev
[1]



Links:
------
[1] http://m5sim.org/mailman/listinfo/gem5-dev
Nilay
2013-02-18 17:43:39 UTC
Permalink
Post by Ali Saidi
Thanks Nilay,
I still haven't groked all your code completely ,but
it seems like perhaps having a #define for TLS_VARIABLE and setting it
to nothing if tls isn't supported and just #ifdefing the control flow
through simulate() might be sufficient to get the job done.
Ali, do you use gem5 on os x? I borrowed a laptop for the weekend, but it
did not have any compiler on it. It seems like I'll have to setup
everything from scratch. A friend of mine suggested that I should look in
to xcode. Is xcode what people use for working with gem5 on os x?

--
Nilay
Andreas Hansson
2013-02-18 17:53:17 UTC
Permalink
Xcode (for clang) + macports (for python, scons, mercurial etc) is what I
use, works like a charm.

Andreas
Post by Nilay
Post by Ali Saidi
Thanks Nilay,
I still haven't groked all your code completely ,but
it seems like perhaps having a #define for TLS_VARIABLE and setting it
to nothing if tls isn't supported and just #ifdefing the control flow
through simulate() might be sufficient to get the job done.
Ali, do you use gem5 on os x? I borrowed a laptop for the weekend, but it
did not have any compiler on it. It seems like I'll have to setup
everything from scratch. A friend of mine suggested that I should look in
to xcode. Is xcode what people use for working with gem5 on os x?
--
Nilay
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Nilay
2013-02-18 18:14:46 UTC
Permalink
Andreas, thanks for the info.

--
Nilay
Post by Andreas Hansson
Xcode (for clang) + macports (for python, scons, mercurial etc) is what I
use, works like a charm.
Andreas
Nilay Vaish
2013-02-22 17:53:10 UTC
Permalink
Post by Nilay Vaish
Post by Steve Reinhardt
Hi Nilay,
Could you see if you can easily #ifdef the __thread commands and the creation of threads such that if the platform doesn't support one or both features we can still compile and run?
Thanks,
Ali
I have added the #ifdef for checking whether or not we are running on linux.
It seems that I would not be able to test on OS X since I do not have access
to a machine on which I can install things on my own. Someone using OS X will
have to confirm whether or not this compiles and runs correctly.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4038
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 22, 2013, 9:50 a.m.)
Review request for Default.
Description
-------
Changeset 9564:d3dbd68263e2
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc 7f9d6e971ada
src/dev/etherlink.cc 7f9d6e971ada
src/python/m5/SimObject.py 7f9d6e971ada
src/python/m5/event.py 7f9d6e971ada
src/python/m5/main.py 7f9d6e971ada
src/python/m5/simulate.py 7f9d6e971ada
src/python/swig/core.i 7f9d6e971ada
src/python/swig/event.i 7f9d6e971ada
src/sim/Root.py 7f9d6e971ada
src/sim/SConscript 7f9d6e971ada
src/sim/core.hh 7f9d6e971ada
src/sim/debug.cc 7f9d6e971ada
src/sim/eventq.hh 7f9d6e971ada
src/sim/eventq.cc 7f9d6e971ada
src/sim/eventq_impl.hh 7f9d6e971ada
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 7f9d6e971ada
src/sim/serialize.hh 7f9d6e971ada
src/sim/serialize.cc 7f9d6e971ada
src/sim/sim_events.hh 7f9d6e971ada
src/sim/sim_events.cc 7f9d6e971ada
src/sim/sim_exit.hh 7f9d6e971ada
src/sim/sim_object.cc 7f9d6e971ada
src/sim/simulate.hh 7f9d6e971ada
src/sim/simulate.cc 7f9d6e971ada
src/sim/stat_control.cc 7f9d6e971ada
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-03-03 20:19:14 UTC
Permalink
Post by Nilay Vaish
Post by Steve Reinhardt
Hi Nilay,
Could you see if you can easily #ifdef the __thread commands and the creation of threads such that if the platform doesn't support one or both features we can still compile and run?
Thanks,
Ali
I have added the #ifdef for checking whether or not we are running on linux.
It seems that I would not be able to test on OS X since I do not have access
to a machine on which I can install things on my own. Someone using OS X will
have to confirm whether or not this compiles and runs correctly.
Ok. I'll try to give it a try today.
Ali


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4038
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 22, 2013, 9:50 a.m.)
Review request for Default.
Description
-------
Changeset 9564:d3dbd68263e2
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc 7f9d6e971ada
src/dev/etherlink.cc 7f9d6e971ada
src/python/m5/SimObject.py 7f9d6e971ada
src/python/m5/event.py 7f9d6e971ada
src/python/m5/main.py 7f9d6e971ada
src/python/m5/simulate.py 7f9d6e971ada
src/python/swig/core.i 7f9d6e971ada
src/python/swig/event.i 7f9d6e971ada
src/sim/Root.py 7f9d6e971ada
src/sim/SConscript 7f9d6e971ada
src/sim/core.hh 7f9d6e971ada
src/sim/debug.cc 7f9d6e971ada
src/sim/eventq.hh 7f9d6e971ada
src/sim/eventq.cc 7f9d6e971ada
src/sim/eventq_impl.hh 7f9d6e971ada
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 7f9d6e971ada
src/sim/serialize.hh 7f9d6e971ada
src/sim/serialize.cc 7f9d6e971ada
src/sim/sim_events.hh 7f9d6e971ada
src/sim/sim_events.cc 7f9d6e971ada
src/sim/sim_exit.hh 7f9d6e971ada
src/sim/sim_object.cc 7f9d6e971ada
src/sim/simulate.hh 7f9d6e971ada
src/sim/simulate.cc 7f9d6e971ada
src/sim/stat_control.cc 7f9d6e971ada
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-03-03 21:40:58 UTC
Permalink
HI Nilay,

I hacked around and almost got it to compile on os x. There was one issue with a vtable on BaseGlobalEvent::BaseEvent not having a viable that I can't seem to get rid of. I can try some more later, but I here is the diff that gets it to linking. I'm not sure if it actually works. In short is becomes a mess of #ifdef. If we go that route I think we should have a variable called GEM5_MULTI_THREAD which we can set to true based on more than just __linux__. However, I'm not necessarily comfortable with the sea of ifdefs. The only other thing that comes to mind is having two separate classes or even source files for the global events one that has locking and one that doesn't. I also learned that pthreads_barrier_t is an optional extension of POSIX threads, and as such OS X doesn't implement it.
Given that and the fact that it's the only place we use anything pthreads, maybe we should build a barrier from std::mutex?

Anyone else have opinions about this?

Thanks,
Ali
This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1667/
Hi Nilay,
Could you see if you can easily #ifdef the __thread commands and the creation of threads such that if the platform doesn't support one or both features we can still compile and run?
Thanks,
Ali
I have added the #ifdef for checking whether or not we are running on linux.
It seems that I would not be able to test on OS X since I do not have access
to a machine on which I can install things on my own. Someone using OS X will
have to confirm whether or not this compiles and runs correctly.
Ok. I'll try to give it a try today.
Ali
- Ali
Review request for Default.
By Nilay Vaish.
Updated Feb. 22, 2013, 9:50 a.m.
Description
Changeset 9564:d3dbd68263e2
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
src/cpu/base.cc (7f9d6e971ada)
src/dev/etherlink.cc (7f9d6e971ada)
src/python/m5/SimObject.py (7f9d6e971ada)
src/python/m5/event.py (7f9d6e971ada)
src/python/m5/main.py (7f9d6e971ada)
src/python/m5/simulate.py (7f9d6e971ada)
src/python/swig/core.i (7f9d6e971ada)
src/python/swig/event.i (7f9d6e971ada)
src/sim/Root.py (7f9d6e971ada)
src/sim/SConscript (7f9d6e971ada)
src/sim/core.hh (7f9d6e971ada)
src/sim/debug.cc (7f9d6e971ada)
src/sim/eventq.hh (7f9d6e971ada)
src/sim/eventq.cc (7f9d6e971ada)
src/sim/eventq_impl.hh (7f9d6e971ada)
src/sim/global_event.hh (PRE-CREATION)
src/sim/global_event.cc (PRE-CREATION)
src/sim/root.cc (7f9d6e971ada)
src/sim/serialize.hh (7f9d6e971ada)
src/sim/serialize.cc (7f9d6e971ada)
src/sim/sim_events.hh (7f9d6e971ada)
src/sim/sim_events.cc (7f9d6e971ada)
src/sim/sim_exit.hh (7f9d6e971ada)
src/sim/sim_object.cc (7f9d6e971ada)
src/sim/simulate.hh (7f9d6e971ada)
src/sim/simulate.cc (7f9d6e971ada)
src/sim/stat_control.cc (7f9d6e971ada)
View Diff
Nilay
2013-03-08 18:23:29 UTC
Permalink
Post by Ali Saidi
HI Nilay,
I hacked around and almost got it to compile on os x. There was one issue
with a vtable on BaseGlobalEvent::BaseEvent not having a viable that I
can't seem to get rid of. I can try some more later, but I here is the
diff that gets it to linking. I'm not sure if it actually works. In short
Can you send me the diff? I have often noticed the mails sent to list do
not have attachments (probably because of the size / type of the
attachment).
Post by Ali Saidi
is becomes a mess of #ifdef. If we go that route I think we should have a
variable called GEM5_MULTI_THREAD which we can set to true based on more
than just __linux__. However, I'm not necessarily comfortable with the sea
of ifdefs. The only other thing that comes to mind is having two separate
classes or even source files for the global events one that has locking
and one that doesn't. I also learned that pthreads_barrier_t is an
optional extension of POSIX threads, and as such OS X doesn't implement
it. Given that and the fact that it's the only place we use anything
pthreads, maybe we should build a barrier from std::mutex?
Now that I am thinking about it, it should be possible to build a barrier
using the atomic variables in C++11.

Lastly, I made some changes to ruby message buffer and I can run memtest
regression test in a multi-threaded fashion. But there are some
assumptions. The buffer is infinite in length, no functional accesses.

--
Nilay
Steve Reinhardt
2013-02-14 19:01:14 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4039
-----------------------------------------------------------



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment3915>

I think this is broken... sp should be gone, and I think the only reason it compiles is because it thinks sp is your format string and that the format string is the first arg.


- Steve Reinhardt
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Feb. 14, 2013, 10:17 a.m.)
Review request for Default.
Description
-------
Changeset 9513:93fc3141ee79
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/cpu/base.cc 615456167b9d
src/dev/etherlink.cc 615456167b9d
src/python/m5/SimObject.py 615456167b9d
src/python/m5/event.py 615456167b9d
src/python/m5/main.py 615456167b9d
src/python/m5/simulate.py 615456167b9d
src/python/swig/core.i 615456167b9d
src/python/swig/event.i 615456167b9d
src/sim/Root.py 615456167b9d
src/sim/SConscript 615456167b9d
src/sim/core.hh 615456167b9d
src/sim/debug.cc 615456167b9d
src/sim/eventq.hh 615456167b9d
src/sim/eventq.cc 615456167b9d
src/sim/eventq_impl.hh 615456167b9d
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 615456167b9d
src/sim/serialize.cc 615456167b9d
src/sim/sim_events.hh 615456167b9d
src/sim/sim_events.cc 615456167b9d
src/sim/sim_exit.hh 615456167b9d
src/sim/sim_object.cc 615456167b9d
src/sim/simulate.hh 615456167b9d
src/sim/simulate.cc 615456167b9d
src/sim/stat_control.cc 615456167b9d
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-02-22 17:50:36 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Feb. 22, 2013, 9:50 a.m.)


Review request for Default.


Description (updated)
-------

Changeset 9564:d3dbd68263e2
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/cpu/base.cc 7f9d6e971ada
src/dev/etherlink.cc 7f9d6e971ada
src/python/m5/SimObject.py 7f9d6e971ada
src/python/m5/event.py 7f9d6e971ada
src/python/m5/main.py 7f9d6e971ada
src/python/m5/simulate.py 7f9d6e971ada
src/python/swig/core.i 7f9d6e971ada
src/python/swig/event.i 7f9d6e971ada
src/sim/Root.py 7f9d6e971ada
src/sim/SConscript 7f9d6e971ada
src/sim/core.hh 7f9d6e971ada
src/sim/debug.cc 7f9d6e971ada
src/sim/eventq.hh 7f9d6e971ada
src/sim/eventq.cc 7f9d6e971ada
src/sim/eventq_impl.hh 7f9d6e971ada
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 7f9d6e971ada
src/sim/serialize.hh 7f9d6e971ada
src/sim/serialize.cc 7f9d6e971ada
src/sim/sim_events.hh 7f9d6e971ada
src/sim/sim_events.cc 7f9d6e971ada
src/sim/sim_exit.hh 7f9d6e971ada
src/sim/sim_object.cc 7f9d6e971ada
src/sim/simulate.hh 7f9d6e971ada
src/sim/simulate.cc 7f9d6e971ada
src/sim/stat_control.cc 7f9d6e971ada

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Nilay Vaish
2013-08-19 23:59:06 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Aug. 19, 2013, 11:59 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
-------

Changeset 9841:5985e0c89872
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

SConstruct 43d22d746e7a
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/core.i 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Steve Reinhardt
2013-08-20 00:23:42 UTC
Permalink
Awesome! It might be a few days before I have a chance to look this over,
but I'm really happy to see it posted.

Thanks, Nilay!

Steve
Post by Nilay Vaish
http://reviews.gem5.org/r/1667/
Review request for Default.
By Nilay Vaish.
*Updated Aug. 19, 2013, 11:59 p.m.*
*Repository: * gem5
Description (updated)
Changeset 9841:5985e0c89872
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs (updated)
- SConstruct (43d22d746e7a)
- src/SConscript (43d22d746e7a)
- src/base/barrier.hh (PRE-CREATION)
- src/cpu/base.cc (43d22d746e7a)
- src/dev/etherlink.cc (43d22d746e7a)
- src/python/m5/SimObject.py (43d22d746e7a)
- src/python/m5/event.py (43d22d746e7a)
- src/python/m5/main.py (43d22d746e7a)
- src/python/m5/simulate.py (43d22d746e7a)
- src/python/swig/core.i (43d22d746e7a)
- src/python/swig/event.i (43d22d746e7a)
- src/sim/Root.py (43d22d746e7a)
- src/sim/SConscript (43d22d746e7a)
- src/sim/core.hh (43d22d746e7a)
- src/sim/debug.cc (43d22d746e7a)
- src/sim/eventq.hh (43d22d746e7a)
- src/sim/eventq.cc (43d22d746e7a)
- src/sim/eventq_impl.hh (43d22d746e7a)
- src/sim/global_event.hh (PRE-CREATION)
- src/sim/global_event.cc (PRE-CREATION)
- src/sim/root.cc (43d22d746e7a)
- src/sim/serialize.hh (43d22d746e7a)
- src/sim/serialize.cc (43d22d746e7a)
- src/sim/sim_events.hh (43d22d746e7a)
- src/sim/sim_events.cc (43d22d746e7a)
- src/sim/sim_exit.hh (43d22d746e7a)
- src/sim/sim_object.cc (43d22d746e7a)
- src/sim/simulate.hh (43d22d746e7a)
- src/sim/simulate.cc (43d22d746e7a)
- src/sim/stat_control.cc (43d22d746e7a)
View Diff <http://reviews.gem5.org/r/1667/diff/>
Nilay Vaish
2013-08-20 03:21:51 UTC
Permalink
Ali and Andreas put in the effort to get the patch compile on OS X. LLVM
team recently (two months back) released version 3.3 which provides
support for TLS. Hence, we can now run with the same code on both Linux
and OS X. In addition, Ali and Andreas also wrote a Barrier class that
uses only C++11 constructs, so we do not need to use pthread's barrier.

I think we can get at least this portion in to the repo. But other changes
which allow us to have different cores and caches running on separate
threads is further away.

--
Nilay
Post by Steve Reinhardt
Awesome! It might be a few days before I have a chance to look this over,
but I'm really happy to see it posted.
Thanks, Nilay!
Steve
Ali Saidi
2013-08-20 08:52:44 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4614
-----------------------------------------------------------



SConstruct
<http://reviews.gem5.org/r/1667/#comment4337>

This needs to be killed after However,... as wer'e doing it now.


- Ali Saidi
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 19, 2013, 11:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:5985e0c89872
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
SConstruct 43d22d746e7a
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/core.i 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-08-20 16:19:33 UTC
Permalink
Post by Nilay Vaish
SConstruct, line 634
<http://reviews.gem5.org/r/1667/diff/7/?file=37125#file37125line634>
This needs to be killed after However,... as wer'e doing it now.
Andreas, please change this comment in your review number 1970.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4614
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 19, 2013, 11:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:5985e0c89872
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
SConstruct 43d22d746e7a
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/core.i 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-08-20 12:42:29 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4615
-----------------------------------------------------------



SConstruct
<http://reviews.gem5.org/r/1667/#comment4338>

I'll push http://reviews.gem5.org/r/1970/ which takes care of this



src/SConscript
<http://reviews.gem5.org/r/1667/#comment4339>

What is causing this to pop up?



src/python/m5/SimObject.py
<http://reviews.gem5.org/r/1667/#comment4340>

Very minor, but could we move this to after the cxx_.* lines?



src/python/m5/simulate.py
<http://reviews.gem5.org/r/1667/#comment4341>

Sporadic whitespace



src/python/m5/simulate.py
<http://reviews.gem5.org/r/1667/#comment4343>

Could you add a line why this has moved here?



src/python/swig/core.i
<http://reviews.gem5.org/r/1667/#comment4342>

Sporadic whitespace



src/python/swig/event.i
<http://reviews.gem5.org/r/1667/#comment4344>

Perhaps I'm missing something here, but how come the Event is no longer an Event? :-)



src/python/swig/event.i
<http://reviews.gem5.org/r/1667/#comment4345>

whitespace



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4346>

Unrelated change?



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4347>

All these unrelated?



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4348>

Is a list a good choice here?



src/sim/sim_events.hh
<http://reviews.gem5.org/r/1667/#comment4349>

const?



src/sim/sim_events.hh
<http://reviews.gem5.org/r/1667/#comment4350>

const?


Looks great! Some minor questions and concerns.

- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 19, 2013, 11:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:5985e0c89872
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
SConstruct 43d22d746e7a
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/core.i 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-08-20 16:18:47 UTC
Permalink
Post by Nilay Vaish
SConstruct, line 640
<http://reviews.gem5.org/r/1667/diff/7/?file=37125#file37125line640>
I'll push http://reviews.gem5.org/r/1970/ which takes care of this
Ok, I'll drop this from the patch.
Post by Nilay Vaish
src/SConscript, line 899
<http://reviews.gem5.org/r/1667/diff/7/?file=37126#file37126line899>
What is causing this to pop up?
Nothing on RHEL 6. May be some OS X issue.
Post by Nilay Vaish
src/python/m5/simulate.py, line 150
<http://reviews.gem5.org/r/1667/diff/7/?file=37133#file37133line150>
Could you add a line why this has moved here?
I am unable to recall exactly. I think things were going wrong if
no simulation took place. The function stats.dump is called if no
simulation has taken place. This function calls curTick() which now
depends on the thread-local event queue. I think queues are not
allocated in some case. The function stats.dump would therefore crash.

I think we should not add this explaination to the code.
Post by Nilay Vaish
src/sim/eventq.hh, line 347
<http://reviews.gem5.org/r/1667/diff/7/?file=37140#file37140line347>
Unrelated change?
Just the formatting is being change.
Post by Nilay Vaish
src/sim/eventq.hh, line 471
<http://reviews.gem5.org/r/1667/diff/7/?file=37140#file37140line471>
Is a list a good choice here?
If you are suggesting that we use a deque, I think there is
no difference in time and space complexities.
Post by Nilay Vaish
src/python/swig/event.i, line 85
<http://reviews.gem5.org/r/1667/diff/7/?file=37135#file37135line85>
Perhaps I'm missing something here, but how come the Event is no longer an Event? :-)
The Event class was split, some parts were moved to the EventBase class.
The class GlobalSimLoopExitEvent is derived from the class GlobalEvent which
is derived from the EventBase class.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4615
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 19, 2013, 11:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:5985e0c89872
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
SConstruct 43d22d746e7a
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/core.i 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-08-20 16:20:42 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Aug. 20, 2013, 4:20 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
-------

Changeset 9841:b42a2994b221
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Steve Reinhardt
2013-09-16 23:33:42 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4696
-----------------------------------------------------------



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4442>

Would it be better to call this curEventQueue? This is a pretty ugly name. (I know, probably my fault originally.)



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4440>

This looks like an irrelevant whitespace-only change.



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4441>

I realize (looking back) that this is my change, but it seems like it needs at least a comment. I'm also surprised that the second unserialize isn't marked virtual. I suppose the right answer ties in with our long-term discussion of checkpointing (see below), but in the short term it would be nice to at least have a comment here. Or is there one somewhere else that I missed?



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4438>

Missing "event" in comment.



src/sim/serialize.cc
<http://reviews.gem5.org/r/1667/#comment4439>

It seems odd that we're generating N identically named "MainEventQueue" sections. I expect that it works fine (since they're processed in order on both ends), but *if* we're going to stick with this model, then we should put indices on the names (perhaps except for queue 0, for backward compatibility).

That said, we should also have a discussion about whether this is the right model at all. In the near term, we should probably stick with it because I don't want to hold things up, but in the long run, do we really want the number of threads to be baked into the checkpoint? I'd argue that checkpoints should be taken at a higher level such that the number of threads can be varied between a save and a restore.


- Steve Reinhardt
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 20, 2013, 9:20 a.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:b42a2994b221
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-09-20 20:59:04 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq.hh, line 70
<http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line70>
Would it be better to call this curEventQueue? This is a pretty ugly name. (I know, probably my fault originally.)
Remained as _curEventQueue.
Post by Nilay Vaish
src/sim/eventq.hh, line 347
<http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line347>
This looks like an irrelevant whitespace-only change.
Rolled back.
Post by Nilay Vaish
src/sim/eventq.hh, line 498
<http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line498>
Missing "event" in comment.
Fixed.
Post by Nilay Vaish
src/sim/serialize.cc, line 462
<http://reviews.gem5.org/r/1667/diff/8/?file=37175#file37175line462>
It seems odd that we're generating N identically named "MainEventQueue" sections. I expect that it works fine (since they're processed in order on both ends), but *if* we're going to stick with this model, then we should put indices on the names (perhaps except for queue 0, for backward compatibility).
That said, we should also have a discussion about whether this is the right model at all. In the near term, we should probably stick with it because I don't want to hold things up, but in the long run, do we really want the number of threads to be baked into the checkpoint? I'd argue that checkpoints should be taken at a higher level such that the number of threads can be varied between a save and a restore.
The naming has been kept as is to avoid having to update the previously
created checkpoints. We can add the queue index after we have worked out
the details of checkpointing when running with multiple queues. As of now,
we can just say that one should create checkpoints only in a single queue
regime.
Post by Nilay Vaish
src/sim/eventq.hh, line 411
<http://reviews.gem5.org/r/1667/diff/8/?file=37168#file37168line411>
I realize (looking back) that this is my change, but it seems like it needs at least a comment. I'm also surprised that the second unserialize isn't marked virtual. I suppose the right answer ties in with our long-term discussion of checkpointing (see below), but in the short term it would be nice to at least have a comment here. Or is there one somewhere else that I missed?
Added a comment.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4696
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 20, 2013, 4:20 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:b42a2994b221
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-09-18 22:07:43 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4706
-----------------------------------------------------------



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment4444>

I don't think this is needed anymore. at least not for os x...





src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment4445>

same


- Ali Saidi
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 20, 2013, 4:20 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:b42a2994b221
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-09-19 08:53:44 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4716
-----------------------------------------------------------



src/base/barrier.hh
<http://reviews.gem5.org/r/1667/#comment4455>

What version of gcc does this require? Will it work with 4.4?

http://gcc.gnu.org/projects/cxx0x.html


- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 20, 2013, 4:20 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:b42a2994b221
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-09-19 21:00:19 UTC
Permalink
Post by Nilay Vaish
src/base/barrier.hh, line 4
<http://reviews.gem5.org/r/1667/diff/8/?file=37156#file37156line4>
What version of gcc does this require? Will it work with 4.4?
http://gcc.gnu.org/projects/cxx0x.html
Condtional_variable is included in 4.4


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4716
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Aug. 20, 2013, 4:20 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9841:b42a2994b221
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 43d22d746e7a
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 43d22d746e7a
src/dev/etherlink.cc 43d22d746e7a
src/python/m5/SimObject.py 43d22d746e7a
src/python/m5/event.py 43d22d746e7a
src/python/m5/main.py 43d22d746e7a
src/python/m5/simulate.py 43d22d746e7a
src/python/swig/event.i 43d22d746e7a
src/sim/Root.py 43d22d746e7a
src/sim/SConscript 43d22d746e7a
src/sim/core.hh 43d22d746e7a
src/sim/debug.cc 43d22d746e7a
src/sim/eventq.hh 43d22d746e7a
src/sim/eventq.cc 43d22d746e7a
src/sim/eventq_impl.hh 43d22d746e7a
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 43d22d746e7a
src/sim/serialize.hh 43d22d746e7a
src/sim/serialize.cc 43d22d746e7a
src/sim/sim_events.hh 43d22d746e7a
src/sim/sim_events.cc 43d22d746e7a
src/sim/sim_exit.hh 43d22d746e7a
src/sim/sim_object.cc 43d22d746e7a
src/sim/simulate.hh 43d22d746e7a
src/sim/simulate.cc 43d22d746e7a
src/sim/stat_control.cc 43d22d746e7a
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-09-20 20:59:38 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Sept. 20, 2013, 8:59 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
-------

Changeset 9882:39ca1efd64fb
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/SConscript 5fad1d2eb314
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 5fad1d2eb314
src/dev/etherlink.cc 5fad1d2eb314
src/python/m5/SimObject.py 5fad1d2eb314
src/python/m5/event.py 5fad1d2eb314
src/python/m5/main.py 5fad1d2eb314
src/python/m5/simulate.py 5fad1d2eb314
src/python/swig/event.i 5fad1d2eb314
src/sim/Root.py 5fad1d2eb314
src/sim/SConscript 5fad1d2eb314
src/sim/core.hh 5fad1d2eb314
src/sim/debug.cc 5fad1d2eb314
src/sim/eventq.hh 5fad1d2eb314
src/sim/eventq.cc 5fad1d2eb314
src/sim/eventq_impl.hh 5fad1d2eb314
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 5fad1d2eb314
src/sim/serialize.hh 5fad1d2eb314
src/sim/serialize.cc 5fad1d2eb314
src/sim/sim_events.hh 5fad1d2eb314
src/sim/sim_events.cc 5fad1d2eb314
src/sim/sim_exit.hh 5fad1d2eb314
src/sim/sim_object.cc 5fad1d2eb314
src/sim/simulate.hh 5fad1d2eb314
src/sim/simulate.cc 5fad1d2eb314
src/sim/stat_control.cc 5fad1d2eb314

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Steve Reinhardt
2013-09-20 22:25:48 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4724
-----------------------------------------------------------

Ship it!


Looks good to me! Thanks so much, Nilay!

- Steve Reinhardt
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 20, 2013, 1:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9882:39ca1efd64fb
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 5fad1d2eb314
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 5fad1d2eb314
src/dev/etherlink.cc 5fad1d2eb314
src/python/m5/SimObject.py 5fad1d2eb314
src/python/m5/event.py 5fad1d2eb314
src/python/m5/main.py 5fad1d2eb314
src/python/m5/simulate.py 5fad1d2eb314
src/python/swig/event.i 5fad1d2eb314
src/sim/Root.py 5fad1d2eb314
src/sim/SConscript 5fad1d2eb314
src/sim/core.hh 5fad1d2eb314
src/sim/debug.cc 5fad1d2eb314
src/sim/eventq.hh 5fad1d2eb314
src/sim/eventq.cc 5fad1d2eb314
src/sim/eventq_impl.hh 5fad1d2eb314
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 5fad1d2eb314
src/sim/serialize.hh 5fad1d2eb314
src/sim/serialize.cc 5fad1d2eb314
src/sim/sim_events.hh 5fad1d2eb314
src/sim/sim_events.cc 5fad1d2eb314
src/sim/sim_exit.hh 5fad1d2eb314
src/sim/sim_object.cc 5fad1d2eb314
src/sim/simulate.hh 5fad1d2eb314
src/sim/simulate.cc 5fad1d2eb314
src/sim/stat_control.cc 5fad1d2eb314
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-09-21 15:38:54 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------



src/base/barrier.hh
<http://reviews.gem5.org/r/1667/#comment4466>

Copyright?



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4467>

Nothing urgent, but is a list really the best choice here?



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4468>

initialize async_queue_mutex to NULL



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4469>

assert async_queue_mutex == NULL



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment4470>

Is the notion of the quantum described somewhere?



src/sim/eventq.cc
<http://reviews.gem5.org/r/1667/#comment4471>

Why not in the initializer list?




src/sim/eventq_impl.hh
<http://reviews.gem5.org/r/1667/#comment4472>

is it worth checking inParallelMode first?

As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)



src/sim/global_event.hh
<http://reviews.gem5.org/r/1667/#comment4473>

Been cooking for a long time? :-)



src/sim/global_event.hh
<http://reviews.gem5.org/r/1667/#comment4475>

I thought we managed to rely entirely on C++11 and avoid pthreads?



src/sim/global_event.hh
<http://reviews.gem5.org/r/1667/#comment4474>

please use || instead of "or"


Some minor comments. One thing I'd like to understand is how this affects the ongoing work to run gem5 together with SystemC (as an SC_THREAD in fact). Does this patch make the SC integration impossible? If so I think there are good reasons to discuss the trade-off in a lot more depth before pushing this.

- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 20, 2013, 8:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9882:39ca1efd64fb
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 5fad1d2eb314
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 5fad1d2eb314
src/dev/etherlink.cc 5fad1d2eb314
src/python/m5/SimObject.py 5fad1d2eb314
src/python/m5/event.py 5fad1d2eb314
src/python/m5/main.py 5fad1d2eb314
src/python/m5/simulate.py 5fad1d2eb314
src/python/swig/event.i 5fad1d2eb314
src/sim/Root.py 5fad1d2eb314
src/sim/SConscript 5fad1d2eb314
src/sim/core.hh 5fad1d2eb314
src/sim/debug.cc 5fad1d2eb314
src/sim/eventq.hh 5fad1d2eb314
src/sim/eventq.cc 5fad1d2eb314
src/sim/eventq_impl.hh 5fad1d2eb314
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 5fad1d2eb314
src/sim/serialize.hh 5fad1d2eb314
src/sim/serialize.cc 5fad1d2eb314
src/sim/sim_events.hh 5fad1d2eb314
src/sim/sim_events.cc 5fad1d2eb314
src/sim/sim_exit.hh 5fad1d2eb314
src/sim/sim_object.cc 5fad1d2eb314
src/sim/simulate.hh 5fad1d2eb314
src/sim/simulate.cc 5fad1d2eb314
src/sim/stat_control.cc 5fad1d2eb314
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Ali Saidi
2013-09-21 16:43:36 UTC
Permalink
Post by Nilay Vaish
Post by Andreas Hansson
Some minor comments. One thing I'd like to understand is how this affects the ongoing work to run gem5 together with SystemC (as an SC_THREAD in fact). Does this patch make the SC integration impossible? If so I think there are good reasons to discuss the trade-off in a lot more depth before pushing this.
Why would it make integration with SC impossible? It might require some changes, but in theory if you were using SC then you could just run it in thread. Either way, being pragmatic this works now. It allows us to thread multiple-systems, and lets us make the KVMCPU work with an MP system.


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 20, 2013, 8:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9882:39ca1efd64fb
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 5fad1d2eb314
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 5fad1d2eb314
src/dev/etherlink.cc 5fad1d2eb314
src/python/m5/SimObject.py 5fad1d2eb314
src/python/m5/event.py 5fad1d2eb314
src/python/m5/main.py 5fad1d2eb314
src/python/m5/simulate.py 5fad1d2eb314
src/python/swig/event.i 5fad1d2eb314
src/sim/Root.py 5fad1d2eb314
src/sim/SConscript 5fad1d2eb314
src/sim/core.hh 5fad1d2eb314
src/sim/debug.cc 5fad1d2eb314
src/sim/eventq.hh 5fad1d2eb314
src/sim/eventq.cc 5fad1d2eb314
src/sim/eventq_impl.hh 5fad1d2eb314
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 5fad1d2eb314
src/sim/serialize.hh 5fad1d2eb314
src/sim/serialize.cc 5fad1d2eb314
src/sim/sim_events.hh 5fad1d2eb314
src/sim/sim_events.cc 5fad1d2eb314
src/sim/sim_exit.hh 5fad1d2eb314
src/sim/sim_object.cc 5fad1d2eb314
src/sim/simulate.hh 5fad1d2eb314
src/sim/simulate.cc 5fad1d2eb314
src/sim/stat_control.cc 5fad1d2eb314
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-09-21 18:33:25 UTC
Permalink
Post by Ali Saidi
src/sim/global_event.hh, line 2
<http://reviews.gem5.org/r/1667/diff/9/?file=37732#file37732line2>
Been cooking for a long time? :-)
Indeed it has... though it was December 2011 when I made the first pass on this code, so it hasn't been *quite* two full years yet. That's why I'm (1) grateful to Nilay for finishing the job and (2) anxious to see this finally get committed.
Post by Ali Saidi
Some minor comments. One thing I'd like to understand is how this affects the ongoing work to run gem5 together with SystemC (as an SC_THREAD in fact). Does this patch make the SC integration impossible? If so I think there are good reasons to discuss the trade-off in a lot more depth before pushing this.
Why would it make integration with SC impossible? It might require some changes, but in theory if you were using SC then you could just run it in thread. Either way, being pragmatic this works now. It allows us to thread multiple-systems, and lets us make the KVMCPU work with an MP system.
I agree with Ali... I'd think that at worst using SystemC and multiple threads would be mutually exclusive runtime options, but I can't see why they would be statically incompatible. Plus since the SystemC stuff is not yet committed, being able to use multiple threads only when we're not doing SystemC is clearly not a near-term limitation ;-). There should be a discussion about how these features work together in the long run, but I don't see a reason to hold up committing this code while we work that out.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Ali Saidi
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 20, 2013, 1:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9882:39ca1efd64fb
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 5fad1d2eb314
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 5fad1d2eb314
src/dev/etherlink.cc 5fad1d2eb314
src/python/m5/SimObject.py 5fad1d2eb314
src/python/m5/event.py 5fad1d2eb314
src/python/m5/main.py 5fad1d2eb314
src/python/m5/simulate.py 5fad1d2eb314
src/python/swig/event.i 5fad1d2eb314
src/sim/Root.py 5fad1d2eb314
src/sim/SConscript 5fad1d2eb314
src/sim/core.hh 5fad1d2eb314
src/sim/debug.cc 5fad1d2eb314
src/sim/eventq.hh 5fad1d2eb314
src/sim/eventq.cc 5fad1d2eb314
src/sim/eventq_impl.hh 5fad1d2eb314
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 5fad1d2eb314
src/sim/serialize.hh 5fad1d2eb314
src/sim/serialize.cc 5fad1d2eb314
src/sim/sim_events.hh 5fad1d2eb314
src/sim/sim_events.cc 5fad1d2eb314
src/sim/sim_exit.hh 5fad1d2eb314
src/sim/sim_object.cc 5fad1d2eb314
src/sim/simulate.hh 5fad1d2eb314
src/sim/simulate.cc 5fad1d2eb314
src/sim/stat_control.cc 5fad1d2eb314
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-09-21 18:33:43 UTC
Permalink
Post by Steve Reinhardt
src/sim/eventq.hh, line 472
<http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line472>
Nothing urgent, but is a list really the best choice here?
If you are suggesting that we use a deque, I think there is
no difference in time and space complexities.
Post by Steve Reinhardt
src/sim/eventq.hh, line 493
<http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line493>
assert async_queue_mutex == NULL
This function is being removed.
Post by Steve Reinhardt
src/sim/eventq.hh, line 489
<http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line489>
initialize async_queue_mutex to NULL
The call EventQueue("") allocates space for the mutex.
Post by Steve Reinhardt
src/sim/eventq.cc, line 50
<http://reviews.gem5.org/r/1667/diff/9/?file=37730#file37730line50>
Is the notion of the quantum described somewhere?
A smallish comment existed in the .hh file. It has been expanded now.
Post by Steve Reinhardt
src/sim/eventq.cc, line 464
<http://reviews.gem5.org/r/1667/diff/9/?file=37730#file37730line464>
Why not in the initializer list?
Done.
Post by Steve Reinhardt
src/sim/global_event.hh, line 2
<http://reviews.gem5.org/r/1667/diff/9/?file=37732#file37732line2>
Been cooking for a long time? :-)
Indeed it has... though it was December 2011 when I made the first pass on this code, so it hasn't been *quite* two full years yet. That's why I'm (1) grateful to Nilay for finishing the job and (2) anxious to see this finally get committed.
Steve originally posted patch in 2011. I have added / updated
copyright holders for most of the files that are being touched
by the patch.
Post by Steve Reinhardt
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 20, 2013, 8:59 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9882:39ca1efd64fb
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 5fad1d2eb314
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 5fad1d2eb314
src/dev/etherlink.cc 5fad1d2eb314
src/python/m5/SimObject.py 5fad1d2eb314
src/python/m5/event.py 5fad1d2eb314
src/python/m5/main.py 5fad1d2eb314
src/python/m5/simulate.py 5fad1d2eb314
src/python/swig/event.i 5fad1d2eb314
src/sim/Root.py 5fad1d2eb314
src/sim/SConscript 5fad1d2eb314
src/sim/core.hh 5fad1d2eb314
src/sim/debug.cc 5fad1d2eb314
src/sim/eventq.hh 5fad1d2eb314
src/sim/eventq.cc 5fad1d2eb314
src/sim/eventq_impl.hh 5fad1d2eb314
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 5fad1d2eb314
src/sim/serialize.hh 5fad1d2eb314
src/sim/serialize.cc 5fad1d2eb314
src/sim/sim_events.hh 5fad1d2eb314
src/sim/sim_events.cc 5fad1d2eb314
src/sim/sim_exit.hh 5fad1d2eb314
src/sim/sim_object.cc 5fad1d2eb314
src/sim/simulate.hh 5fad1d2eb314
src/sim/simulate.cc 5fad1d2eb314
src/sim/stat_control.cc 5fad1d2eb314
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-09-21 18:40:59 UTC
Permalink
Post by Steve Reinhardt
src/sim/global_event.hh, line 2
<http://reviews.gem5.org/r/1667/diff/9/?file=37732#file37732line2>
Been cooking for a long time? :-)
Indeed it has... though it was December 2011 when I made the first pass on this code, so it hasn't been *quite* two full years yet. That's why I'm (1) grateful to Nilay for finishing the job and (2) anxious to see this finally get committed.
Steve originally posted patch in 2011. I have added / updated
copyright holders for most of the files that are being touched
by the patch.
My mistake... I posted these patches in 2011 (which was apparently when I added the copyright notice), but it was actually December *2010* when I wrote most of the code. Yikes.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Steve Reinhardt
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 11:36 a.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
nathan binkert
2013-09-21 18:48:26 UTC
Permalink
Post by Steve Reinhardt
My mistake... I posted these patches in 2011 (which was apparently when I added the copyright notice), but it was actually December *2010* when I wrote most of the code. Yikes.
Oh, come on, my python stats code was mostly written in 2004 and it
still isn't in the tree. :)

Nate
Andreas Hansson
2013-09-21 19:17:21 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result.
Post by Nilay Vaish
src/sim/eventq.hh, line 472
<http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line472>
Nothing urgent, but is a list really the best choice here?
If you are suggesting that we use a deque, I think there is
no difference in time and space complexities.
It's fine. I'm not too worried about the time complexity. Vectors are nice and sequential in memory, lists are scattered all over the place (with some interesting effects http://ecn.channel9.msdn.com/events/GoingNative12/GN12Cpp11Style.pdf).

Anyhow, let's wait with the tweaking until we have some more conclusive performance numbers to base it on.
Post by Nilay Vaish
Some minor comments. One thing I'd like to understand is how this affects the ongoing work to run gem5 together with SystemC (as an SC_THREAD in fact). Does this patch make the SC integration impossible? If so I think there are good reasons to discuss the trade-off in a lot more depth before pushing this.
Why would it make integration with SC impossible? It might require some changes, but in theory if you were using SC then you could just run it in thread. Either way, being pragmatic this works now. It allows us to thread multiple-systems, and lets us make the KVMCPU work with an MP system.
I agree with Ali... I'd think that at worst using SystemC and multiple threads would be mutually exclusive runtime options, but I can't see why they would be statically incompatible. Plus since the SystemC stuff is not yet committed, being able to use multiple threads only when we're not doing SystemC is clearly not a near-term limitation ;-). There should be a discussion about how these features work together in the long run, but I don't see a reason to hold up committing this code while we work that out.
Don't get me wrong, I'm not saying there will be trouble. I am merely hoping to understand what this does to the SystemC line of work, and how it would interact. SystemC natively support the notion of multiple threads with quantum-based synchronisation, but the openly available implementation is still single threaded. We should at least understand what pain might arise in the merging of the two. I fully agree that multiple event queues is a useful addition.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-09-22 09:03:17 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result.
Ok, so a full regression run, including compilation of all ISAs is now 18% slower. This is a fairly accurate measure of the slowdown, as the run time is within +-10 min over the last months.

This suggests actual simulation is more than 18% slower, which obviously is a _big_ issue. I haven't done any profiling, but will keep you posted on any findings.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Steve Reinhardt
2013-09-23 02:38:35 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result.
Ok, so a full regression run, including compilation of all ISAs is now 18% slower. This is a fairly accurate measure of the slowdown, as the run time is within +-10 min over the last months.
This suggests actual simulation is more than 18% slower, which obviously is a _big_ issue. I haven't done any profiling, but will keep you posted on any findings.
That is painful. I hope that we can identify the source of the overhead and solve it with (at worst) some special-casing on (numEventQueues == 1) that isn't too intrusive or ugly.

Thanks for thinking of this... it didn't even occur to me to check.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 11:36 a.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-09-23 07:28:26 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result.
Ok, so a full regression run, including compilation of all ISAs is now 18% slower. This is a fairly accurate measure of the slowdown, as the run time is within +-10 min over the last months.
This suggests actual simulation is more than 18% slower, which obviously is a _big_ issue. I haven't done any profiling, but will keep you posted on any findings.
That is painful. I hope that we can identify the source of the overhead and solve it with (at worst) some special-casing on (numEventQueues == 1) that isn't too intrusive or ugly.
Thanks for thinking of this... it didn't even occur to me to check.
I've got a second point now as well, and after fixing the PC regressions that were failing (see remark below), the total runtime of the regressions is now up 19% (including a clean compile of all ISAs). I haven't done any profiling as of yet.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-09-23 18:33:52 UTC
Permalink
Post by Andreas Hansson
Post by Nilay Vaish
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result.
Ok, so a full regression run, including compilation of all ISAs is now 18% slower. This is a fairly accurate measure of the slowdown, as the run time is within +-10 min over the last months.
This suggests actual simulation is more than 18% slower, which obviously is a _big_ issue. I haven't done any profiling, but will keep you posted on any findings.
That is painful. I hope that we can identify the source of the overhead and solve it with (at worst) some special-casing on (numEventQueues == 1) that isn't too intrusive or ugly.
Thanks for thinking of this... it didn't even occur to me to check.
I've got a second point now as well, and after fixing the PC regressions that were failing (see remark below), the total runtime of the regressions is now up 19% (including a clean compile of all ISAs). I haven't done any profiling as of yet.
So I just ran the regression test: 30.eon for alpha architecture, five
times with and with out the patch. I am seeing improved times for the
simulation when the patch is applied.

Original: 3m 23.54s, 3m 23.405s, 3m 23.235s, 3m 23.925s, 3m 23.138s

With the patch: 3m 3.39s, 2m 59.65s, 3m 1.01s, 3m 1.499s, 3m 1.004s


I read the patch and I am not able to come up with reasons why the times
should change considerably (unless tls has a significant affect).

--
Nilay
Andreas Hansson
2013-09-24 07:26:33 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq_impl.hh, line 55
<http://reviews.gem5.org/r/1667/diff/9/?file=37731#file37731line55>
is it worth checking inParallelMode first?
As a side not, do we know what the performance impact is when not running in parallel mode? (perhaps this has been resolved already)
I'll run the regression tests and report the execution time differences soon.
My _very_ early results suggest around -15% host_inst_rate for most of the regressions, but I'll get back to you tomorrow with a more conclusive result.
Ok, so a full regression run, including compilation of all ISAs is now 18% slower. This is a fairly accurate measure of the slowdown, as the run time is within +-10 min over the last months.
This suggests actual simulation is more than 18% slower, which obviously is a _big_ issue. I haven't done any profiling, but will keep you posted on any findings.
That is painful. I hope that we can identify the source of the overhead and solve it with (at worst) some special-casing on (numEventQueues == 1) that isn't too intrusive or ugly.
Thanks for thinking of this... it didn't even occur to me to check.
I've got a second point now as well, and after fixing the PC regressions that were failing (see remark below), the total runtime of the regressions is now up 19% (including a clean compile of all ISAs). I haven't done any profiling as of yet.
And the third point is withing 1% of the last two ones, and again it is 19% slower. I'll remove your patch again and report back on the change tomorrow.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4727
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-09-24 14:25:14 UTC
Permalink
Post by Andreas Hansson
And the third point is withing 1% of the last two ones, and again it is 19% slower. I'll remove your patch again and report back on the change tomorrow.
Andreas, can you time the tests that switch cpus repeatedly separately? I
ran one se (30.eon) and one fs (x86 pc-o3-timing) test and did not find
much difference. I want to test the hypothesis that a major slowdown has
occurred in those switch cpu tests.

Thanks
Nilay
Nilay Vaish
2013-09-24 21:44:00 UTC
Permalink
Post by Andreas Hansson
And the third point is withing 1% of the last two ones, and again it is 19%
slower. I'll remove your patch again and report back on the change
tomorrow.
Andreas, can you time the tests that switch cpus repeatedly separately? I ran
one se (30.eon) and one fs (x86 pc-o3-timing) test and did not find much
difference. I want to test the hypothesis that a major slowdown has occurred
in those switch cpu tests.
I ran the pc-switcheroo-full test with and without the patch, three times
each. I got almost similar execution times for all the runs.

With out the patch: 20m38.406s 21m14.388s 20m30.755s
With the patch: 21m0.801s 20m40.340s 20m33.649s


Andreas, can you time each test individually and figure out which
regression test(s) are worse off?

--
Nilay
Andreas Hansson
2013-09-25 08:22:11 UTC
Permalink
Hi Nilay,

I'm afraid I won't have time to do that until next week sometime.

In the meanwhile I have re-verified that the regressions are indeed
getting 19% slower (by disabling your patch again). ~13hr with and ~11hr
without.

Andreas
Post by Nilay Vaish
Post by Andreas Hansson
And the third point is withing 1% of the last two ones, and again it is
19% slower. I'll remove your patch again and report back on the change
tomorrow.
Andreas, can you time the tests that switch cpus repeatedly separately? I
ran one se (30.eon) and one fs (x86 pc-o3-timing) test and did not find
much difference. I want to test the hypothesis that a major slowdown has
occurred in those switch cpu tests.
Thanks
Nilay
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Nilay
2013-09-25 22:46:52 UTC
Permalink
Post by Steve Reinhardt
Hi Nilay,
I'm afraid I won't have time to do that until next week sometime.
In the meanwhile I have re-verified that the regressions are indeed
getting 19% slower (by disabling your patch again). ~13hr with and ~11hr
without.
Can you run just one of the tests (one that runs long enough, may be
pc-o3-timing or pc-switcheroo-full)? Since the changes are to the
simulation core and not to some particular architecture / hardware
subsystem, I expect each regression test to slowdown by a similar
factor.

--
Nilay
Nilay Vaish
2013-10-08 17:32:30 UTC
Permalink
Post by Steve Reinhardt
Hi Nilay,
I'm afraid I won't have time to do that until next week sometime.
In the meanwhile I have re-verified that the regressions are indeed
getting 19% slower (by disabling your patch again). ~13hr with and ~11hr
without.
Andreas, were you able to find time to figure out which regression tests
are affected by this change? You just need to grep for host_seconds on the
output from two runs.

--
Nilay
Andreas Hansson
2013-10-08 17:37:46 UTC
Permalink
Hi Nilay,

Unfortunately I haven't found the time to dig into this yet.

I only have the output from last nights regression, and thus not with and
without your patch. I'll take a snapshot and compare, although I suspect
the individual runs vary quite a bit.

Have you attempted any further profiling?

Andreas
Post by Nilay Vaish
Post by Steve Reinhardt
Hi Nilay,
I'm afraid I won't have time to do that until next week sometime.
In the meanwhile I have re-verified that the regressions are indeed
getting 19% slower (by disabling your patch again). ~13hr with and ~11hr
without.
Andreas, were you able to find time to figure out which regression tests
are affected by this change? You just need to grep for host_seconds on the
output from two runs.
--
Nilay
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Nilay
2013-10-11 17:47:19 UTC
Permalink
Post by Steve Reinhardt
Hi Nilay,
Unfortunately I haven't found the time to dig into this yet.
I only have the output from last nights regression, and thus not with and
without your patch. I'll take a snapshot and compare, although I suspect
the individual runs vary quite a bit.
Have you attempted any further profiling?
No, I have not. Are you running on OS X?

--
Nilay
Nilay Vaish
2013-09-21 18:36:53 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Sept. 21, 2013, 6:36 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
-------

Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Andreas Hansson
2013-09-21 19:21:55 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4733
-----------------------------------------------------------



src/sim/eventq.hh
<http://reviews.gem5.org/r/1667/#comment4487>

Sorry, I might be missing something here, but in the constructor of EventQueue, you create a private EventQueue that lives in the local scope and is essentially a no-op. Right?

And this allocates space?

Perhaps it's some nifty pattern that I'm not familiar with, but I must confess I'm confused.


- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-09-22 23:05:45 UTC
Permalink
Post by Nilay Vaish
src/sim/eventq.hh, line 489
<http://reviews.gem5.org/r/1667/diff/9/?file=37729#file37729line489>
Sorry, I might be missing something here, but in the constructor of EventQueue, you create a private EventQueue that lives in the local scope and is essentially a no-op. Right?
And this allocates space?
Perhaps it's some nifty pattern that I'm not familiar with, but I must confess I'm confused.
Nothin nifty here. The piece of code is not in use and is therefore being removed.


- Nilay


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4733
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-09-22 16:22:21 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4735
-----------------------------------------------------------


One additional issue:

Somehow the unproxying of the eventq_index does not work for the PC regressions due to some odd circular relationship. The change below is needed for it to work again.

diff --git a/src/dev/x86/Pc.py b/src/dev/x86/Pc.py
--- a/src/dev/x86/Pc.py
+++ b/src/dev/x86/Pc.py
@@ -57,10 +57,9 @@
behind_pci = IsaFake(pio_addr=x86IOAddress(0xcf8), pio_size=8)

# Serial port and terminal
- terminal = Terminal()
com_1 = Uart8250()
com_1.pio_addr = x86IOAddress(0x3f8)
- com_1.terminal = terminal
+ com_1.terminal = Terminal()

# Devices to catch access to non-existant serial ports.
fake_com_2 = IsaFake(pio_addr=x86IOAddress(0x2f8), pio_size=8)


- Andreas Hansson
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Andreas Hansson
2013-11-20 17:40:33 UTC
Permalink
Post by Nilay Vaish
Post by Andreas Hansson
Somehow the unproxying of the eventq_index does not work for the PC regressions due to some odd circular relationship. The change below is needed for it to work again.
diff --git a/src/dev/x86/Pc.py b/src/dev/x86/Pc.py
--- a/src/dev/x86/Pc.py
+++ b/src/dev/x86/Pc.py
@@ -57,10 +57,9 @@
behind_pci = IsaFake(pio_addr=x86IOAddress(0xcf8), pio_size=8)
# Serial port and terminal
- terminal = Terminal()
com_1 = Uart8250()
com_1.pio_addr = x86IOAddress(0x3f8)
- com_1.terminal = terminal
+ com_1.terminal = Terminal()
# Devices to catch access to non-existant serial ports.
fake_com_2 = IsaFake(pio_addr=x86IOAddress(0x2f8), pio_size=8)
Hi Nilay,

I wanted to give this another bash, but the patch does no longer apply cleanly. Is this something you've bumped in to?

Thanks.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/#review4735
-----------------------------------------------------------
Post by Nilay Vaish
-----------------------------------------------------------
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------
(Updated Sept. 21, 2013, 6:36 p.m.)
Review request for Default.
Repository: gem5
Description
-------
Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.
We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.
Diffs
-----
src/SConscript 372d3611c693
src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 372d3611c693
src/dev/etherlink.cc 372d3611c693
src/python/m5/SimObject.py 372d3611c693
src/python/m5/event.py 372d3611c693
src/python/m5/main.py 372d3611c693
src/python/m5/simulate.py 372d3611c693
src/python/swig/event.i 372d3611c693
src/sim/Root.py 372d3611c693
src/sim/SConscript 372d3611c693
src/sim/core.hh 372d3611c693
src/sim/core.cc 372d3611c693
src/sim/debug.cc 372d3611c693
src/sim/eventq.hh 372d3611c693
src/sim/eventq.cc 372d3611c693
src/sim/eventq_impl.hh 372d3611c693
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 372d3611c693
src/sim/serialize.hh 372d3611c693
src/sim/serialize.cc 372d3611c693
src/sim/sim_events.hh 372d3611c693
src/sim/sim_events.cc 372d3611c693
src/sim/sim_exit.hh 372d3611c693
src/sim/sim_object.cc 372d3611c693
src/sim/simulate.hh 372d3611c693
src/sim/simulate.cc 372d3611c693
src/sim/stat_control.cc 372d3611c693
Diff: http://reviews.gem5.org/r/1667/diff/
Testing
-------
Thanks,
Nilay Vaish
Nilay Vaish
2013-11-20 19:58:49 UTC
Permalink
Post by Steve Reinhardt
Post by Andreas Hansson
Somehow the unproxying of the eventq_index does not work for the PC regressions due to some odd circular relationship. The change below is needed for it to work again.
diff --git a/src/dev/x86/Pc.py b/src/dev/x86/Pc.py
--- a/src/dev/x86/Pc.py
+++ b/src/dev/x86/Pc.py
@@ -57,10 +57,9 @@
behind_pci = IsaFake(pio_addr=x86IOAddress(0xcf8), pio_size=8)
# Serial port and terminal
- terminal = Terminal()
com_1 = Uart8250()
com_1.pio_addr = x86IOAddress(0x3f8)
- com_1.terminal = terminal
+ com_1.terminal = Terminal()
# Devices to catch access to non-existant serial ports.
fake_com_2 = IsaFake(pio_addr=x86IOAddress(0x2f8), pio_size=8)
Hi Nilay,
I wanted to give this another bash, but the patch does no longer apply cleanly. Is this something you've bumped in to?
Thanks.
I have uploaded the latest version.

--
Nilay

Nilay Vaish
2013-11-20 19:55:29 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1667/
-----------------------------------------------------------

(Updated Nov. 20, 2013, 7:55 p.m.)


Review request for Default.


Repository: gem5


Description
-------

Changeset 9885:ab020183761b
---------------------------
sim: simulate with multiple event queues
This patch extends the patch Steve posted on the reviewboard (846). The patch
updated with all the changes that have taken place over last 15 months. Code
has been added so as actually carry out a quantum-based parallel simulation.

The patch was tested in two different configurations:
1. ruby_network_test.py: in this simulation L1 cache controllers receive
requests from the cpu. The requests are replied to immediately without
any communication taking place with any other level.
2. twosys-tsunami-simple-atomic: this configuration simulates a client-server
system which are connected by an ethernet link.

We still lack the ability to communicate using message buffers or ports. But
other things like simulation start and end, synchronizing after every quantum
seem to be working.


Diffs (updated)
-----

src/base/barrier.hh PRE-CREATION
src/cpu/base.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/cpu/kvm/base.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/dev/etherlink.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/dev/x86/Pc.py 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/python/m5/SimObject.py 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/python/m5/event.py 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/python/m5/main.py 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/python/m5/simulate.py 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/python/swig/event.i 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/Root.py 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/SConscript 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/core.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/core.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/debug.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/eventq.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/eventq.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/eventq_impl.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/global_event.hh PRE-CREATION
src/sim/global_event.cc PRE-CREATION
src/sim/root.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/serialize.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/serialize.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/sim_events.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/sim_events.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/sim_exit.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/sim_object.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/simulate.hh 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/simulate.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee
src/sim/stat_control.cc 329b8a20958ba774ec59bc9e1848c3c5de85a0ee

Diff: http://reviews.gem5.org/r/1667/diff/


Testing
-------


Thanks,

Nilay Vaish
Loading...