* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
*
I'm not the guy to ask for that... but actually I doubt the protocol itself
matters that much, you just need to look at the code path that gets
exercised on an L1 cache hit and see where the calls are. That part should
be almost if not entirely independent of the coherence protocol.
Steve
On
On Fri, 12 Nov 2010, Steve Reinhardt wrote:
Right now I am profiling with coherence protocol as MOESI_hammer. I am
thinking of profiling using a different protocol to make sure that it is not
an artifact of the protocol in use.
That sounds like a good idea.
All in all, we would ideally
On 2010-11-15 21:46:47, Nathan Binkert wrote:
src/arch/arm/isa/operands.isa, line 89
http://reviews.m5sim.org/r/312/diff/1/?file=5179#file5179line89
Ok, I thought I commented on this last time. This is nuts. You can't
have this random number here that needs to change whenever
I was looking at the MOESI hammer protocol. I think Steve's observation
that extra tag lookups are going on in the cache is correct. In particular
I noticed that in the getState() and setState() functions, first
isTagPresent(address) is called and on the basis of the result (which is
true or
Even if the named constant is in the same file just above where it is used,
that is far better than using the same number in 50 different places. It is
worth it because of exactly what's going on right now. You're submitting
your 2nd 50 lines of diff to change one number in 50 places. Not cool.
