On Thu, 14 Jul 2011, Hamid Reza Khaleghzadeh wrote:
Hi
Thanks for your answer Nilay. I have run the application two times. First
time, number of iteration is 100 times and in second time, for loop is run
300 times. These are number of ruby-cycles that taken for running
application:
Iteration=100 and Cores 2,3 -> Ruby-cycles= *116030060
*Iteration=100 and Cores 2,4 -> Ruby-cycles= *119546137*
Iteration=300 and Cores 2,3 -> Ruby-cycles= *346324353*
Iteration=300 and Cores 2,4 -> Ruby-cycles= *357471770*
It's clear that number of cycles when app runs on shared L2 and distinct one
must be different. For first run, cycles difference is 3516077 (=*119546137
- * *116030060) *and for second one is 11147417. Could you tell me why
difference of cycles is increased when number of iteration is increased?
Why do you expect the difference not to increase? If you expect all reads
to be satisfied from the L2 cache, then may be you should look at the
number of L2 misses.
By the way, I have another question about MOESI-CMP-directory. If possible
please answer it. Consider described architecture in my last post. Suppose
only DL1 of Core2 has data X. At this point, Core3 (Cores 2 and 3 belong to
same ship and have a shared L2) requests X. There are two approaches for
responding to this request.
1- Directory set state of X to SHARE and then read data from L2.
2- Without any access to directory, data read from L2 and state of X doesn't
change.
I think 2 is correct. Could you help me?
I think the implementation that I am versed with, the directory controller
is part of the L2 cache controller itself. In this case, the L2 controller
will set the state to shared. Note that the state has to be set to shared
in at least the L2 controller, since when core 2 had the data, the state
could have been exclusive.
--
Nilay
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
