Hi all,
I need to run some simulation with about 256 cores. So far I only find two
benchmarks from parsec2.1 which can work alright with X86_SE with 256
num.cpus. I wonder if someone has benchmarks which work well with gem5 for
256 cores or can tell me a better/right way to run 256 cores with GEM5
r FS mode, you need to have a linux kernel compiled with the ability to
> handle 256 cores
>
> On Mon, Jun 25, 2012 at 9:38 AM, gem5 gem5 wrote:
>
>> Hi all,
>>
>> I need to run some simulation with about 256 cores. So far I only find
>> two benchmarks from parsec2
gt;
> could you please let us know the instructions you have taken to compile
> parsec with pthread? I'd really appreciate it.
>
>
> On Mon, Jun 25, 2012 at 10:29 AM, gem5 gem5 wrote:
>
>> I checked the output when running 256 threads with X86 SE and its 99% the
>>
n Mon, Jun 25, 2012 at 5:20 AM, Hossein Nikoonia wrote:
> i know linux can have 256 or more pthreads running but i don't know if it
> can fully utilize 256 cores.
>
> can you post your modified makefiles?
>
>
>
> On Mon, Jun 25, 2012 at 10:48 AM, gem5 gem5 wrote:
>
&
Hi all,
I want to implement a special interconnection network: a request from one
node is always broadcast to all the other nodes with real
destination ID/address set in the request. For all the other nodes, after
they receive the broadcast request, they compare their own ID/address with
the desti
Hi all,
I want to modify MOESI_hammer protocol to broadcast all the messages. Since
multicast is supported, I think it's possible to do this. I got some
problem with my first step. When I
modify out_msg.Destination.broadcast(MachineType:L1Cache); to
be out_msg.Destination.broadcast() which I assu
that
> these messages are being inserted into some message buffer that is not part
> of the protocol specifications and hence this error shows up.
>
>
> - Tushar
>
>
> On Jul 25, 2012, at 5:29 PM, gem5 gem5 wrote:
>
> > Hi all,
> >
> > I want to modify MO
to handle the extra messages.
>
> The two broadcast based protocols provided with gem5 are MOESI_hammer
> (where a directory broadcasts to all L1s) and MOESI_CMP_token, where L1's
> broadcast to all L2s …
>
> cheers,
> Tushar
>
>
> On Jul 26, 2012, at 6:21 PM, gem5 gem5
dividual messages at the
> source, one for each destination and sent out.
> If you use the simple network, the switch models there can handle
> broadcasts. You could perhaps use that as a starting point and then edit
> the code to model the crossbar you want.
>
> cheers,
> Tusha
Oh, I forgot to ask that if I also need to build hierarchical switch
topology for the MOSI_SMP_bcast protocol to guarantee the order required or
the current GEM5 supports that alreadyThanks.
Best,
Jinzhu
On Fri, Jul 27, 2012 at 3:20 PM, gem5 gem5 wrote:
> Hi Tushar,
>
> Your su
ocol in gem5 (such as MOESI_hammer) to
> always perform broadcasts.
>
> cheers,
> Tushar
>
>
> On Jul 27, 2012, at 3:49 PM, gem5 gem5 wrote:
>
> Oh, I forgot to ask that if I also need to build hierarchical switch
> topology for the MOSI_SMP_bcast protocol to guarantee the order
asier for
> you to understand and closer to what you wish to do, and then go along that
> direction.
>
> It should not be hard to code any topology, including hierarchical switch
> in gem5.
>
> All the best!
> Tushar
>
>
> On Jul 27, 2012, at 6:36 PM, gem5 gem5 wrote
Hi all,
I want to move the MOSI_SMP_bcast protocol from GEMS to GEM5. I modified
the original MOSI_SMP_bcast_1level protocol to
become MOSI_CMP_bcast_1level. However, when I ran it
with ruby_random_test.py on Crossbar topology ( build/X86_SE/gem5.opt
--debug-flags=Ruby configs/example/ruby_random_
Does anyone have some suggestions? I still couldn't figure it
out.thanks!
Jinzhu
On Tue, Jul 31, 2012 at 6:50 PM, gem5 gem5 wrote:
> Hi all,
>
> I want to move the MOSI_SMP_bcast protocol from GEMS to GEM5. I modified
> the original MOSI_SMP_bcast_1level pro
/build/X86_SE/gem5.opt --debug-flags=ProtocolTrace
> configs/example/ruby_random_test.py --num-cpus=4 --num-dirs=1
> --topology=Crossbar --garnet-network=flexible
>
> Look at the requests/responses for that address and figure out what went
> wrong…
>
> cheers,
> Tushar
>
>
rk switch itself to model your design (but the simple network
> has a fuzzy congestion model), or plug in garnet (if you want a more
> detailed network model) and add broadcast support to it.
>
> - Tushar
>
>
>
> On 08/06/2012 05:00 PM, gem5 gem5 wrote:
>
> Hi Tushar,
&g
Hi,
I have created a logic bus to run a broadcast protocol which requires total
ordering in ruby simple network. It works. Now I need to have multiple
logic buses. To achieve total ordering among different buses, each
cache/directory controller needs to listen to all the buses according to a
prede
be solved by a particular wakeup order, you could look
> into the event queue to see if you can create some order between events
> with the same time. I don't have any experience with that though...
>
> - Tushar
>
>
> On Aug 9, 2012, at 5:37 PM, gem5 gem5 wrote:
>
> >
ign should provide total
order. Any comments?
Thank you very much!
Best,
Jinzhu
On Fri, Aug 10, 2012 at 9:58 PM, gem5 gem5 wrote:
> Tushar,
>
> Thank you very much. Yes, I guess all the routers are connected to the
> same MessageBuffer and each router represents a logic bus. I think
__doc__': None, '__package__': None},
flags=)
at ../Python/pythonrun.c:1309
#34 0x00e95a54 in m5Main (argc=5, argv=0x7fffe008) at
build/X86_SE/sim/init.cc:256
#35 0x0040a44b in main (argc=5, argv=0x7fffe008) at
build/X86_SE/sim/main.cc:57
On Fri, Aug 24
, Aug 23, 2012 at 10:07 PM, gem5 gem5 wrote:
> Thank you very much, Tushar:)
>
> Best,
>
> Jinzhu
>
>
> On Wed, Aug 22, 2012 at 12:24 AM, Tushar Krishna wrote:
>
>> Hi Jinzhu,
>> Do the orange routers guarantee that the message is delivered out of all
>
Actually Pt2Pt will also have a deadlock if the sim cycles are that
many.
On Tue, Aug 28, 2012 at 1:57 AM, gem5 gem5 wrote:
> Hi Tushar,
>
> I wonder if all the nodes(controllers) need to have a router before them.
> This is what I have seen for all the topologies created in
st
>
> Don't know how controllers work with multiple input links. I think they
> should work fine.
> In any case, if you get deadlocks, look at the protocol trace to figure
> out what went wrong…
>
> - Tushar
>
>
> On Aug 28, 2012, at 3:38 AM, gem5 gem5 wrote:
>
23 matches
Mail list logo
