Hi Nilay,

I don't see a benefit to what you're proposing, but if you do, please
elaborate.  This patch already provides multiple event queues with
different threads, so my naive reading of your question sounds like you
want to take incremental steps toward a place we're already at.  I'm
guessing that I'm not understanding your purpose here.

Also, I find the reviewboard comment/reply interface a little awkward, so I
prefer to keep higher-level discussions on the list directly.

Steve


On Tue, Apr 3, 2012 at 10:05 PM, Nilay Vaish <[email protected]> wrote:

>    This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/846/
>
> Steve, does it make sense to first have multiple event queues handled by a
> single thread, then move towards letting different threads handle these
> queues?
>
>
> - Nilay
>
> On September 6th, 2011, 2:26 p.m., Steve Reinhardt wrote:
>   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
> By Steve Reinhardt.
>
> *Updated Sept. 6, 2011, 2:26 p.m.*
> Description
>
> sim: initial stab at multiple event queues.
> This patch creates multiple event queues.  SimObjects
> specify via the new eventq_index parameter which queue
> they want to schedule on.  The number of event queues
> (and thus threads) is controlled implicitly by the max
> value of eventq_index.
>
> This code seems to work in that multiple event queues
> can be created and events scheduled on an alternate
> queue (by changing the default eventq_index value in
> SimObject.py).  However, without additional synchronization,
> spreading communicating SimObjects across separate
> queues will not work.
>
> This patch is not intended to be definitive, or to be
> considered for committing in anything like the current
> form, but just an initial attempt to make something that
> works that we can build and improve upon.
>
> This patch depends on two prior patches:
> - "pseudo_inst: clean up workbegin/workend functions" (844)
> - "event: minor cleanup" (845)
>
>   Diffs
>
>    - src/cpu/base.cc (b3585da1f970)
>    - src/cpu/simple/atomic.cc (b3585da1f970)
>    - src/mem/ruby/system/System.cc (b3585da1f970)
>    - src/python/m5/SimObject.py (b3585da1f970)
>    - src/python/m5/event.py (b3585da1f970)
>    - src/python/swig/event.i (b3585da1f970)
>    - src/sim/SConscript (b3585da1f970)
>    - src/sim/core.hh (b3585da1f970)
>    - src/sim/core.cc (b3585da1f970)
>    - src/sim/debug.cc (b3585da1f970)
>    - src/sim/eventq.hh (b3585da1f970)
>    - src/sim/eventq.cc (b3585da1f970)
>    - src/sim/global_event.hh (PRE-CREATION)
>    - src/sim/global_event.cc (PRE-CREATION)
>    - src/sim/serialize.cc (b3585da1f970)
>    - src/sim/sim_events.hh (b3585da1f970)
>    - src/sim/sim_events.cc (b3585da1f970)
>    - src/sim/sim_exit.hh (b3585da1f970)
>    - src/sim/sim_object.cc (b3585da1f970)
>    - src/sim/sim_object_params.hh (b3585da1f970)
>    - src/sim/simulate.hh (b3585da1f970)
>    - src/sim/simulate.cc (b3585da1f970)
>    - src/sim/stat_control.cc (b3585da1f970)
>
> View Diff <http://reviews.gem5.org/r/846/diff/>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to