Hi George,
The eviction policy for L1 caches is an important part of the coherence
protocol. The default protocol for CMPs uses a directory that tracks the
precise list of sharers of every block. This requires that the L2 cache
be notified when an L1 evicts any cache line, even those which don't
need to be written back to the L2 cache.
When simulating a single CMP system, there is no need for the L2 cache
to send notifications on clean evictions because there is only one CMP
there is no inter-chip coherence protocol.
I believe there is support in Flexus for a coherence protocol that does
NOT require using clean evictions from the L1 cache, but I'd have to
double check what other changes that might require, I believe that would
require a configuration setting to use a slightly different coherence
protocol.
The messages you are seeing when the L1 performs an evict represent the
message being sent by the L1 and then received by the L2. This is the
same eviction, but the communication from L1 to L2 is reported at both
ends. This can be useful if debug messages are turned off for one of the
components. But you shouldn't be worried, the L2 isn't generating a
message here.
Note that in the timing model, evictions from the L1 are acknowledged by
the L2 to avoid race conditions. In this case, an EvictClean from an L1
would generate an EvictAck reply from the L2.
Jason
On 11-05-02 8:46 AM, George Ioannidis wrote:
Hello,
Among the cache parameters in user-postload.simics, the following is
defined:
flexus.set "-L1d:clean_evict" "1" # "Issue clean evictions"
(CleanEvictions) -- trace
flexus.set "-L1d:allow_evict_clean" "1" # "Cause the cache to evict
clean blocks" (EvictClean) -- timing
which is set (1) for L1 caches and cleared (0) for L2 caches. I would
like to ask what difference does it make in the eviction policy of the
CMP system.
Furthermore, I see in debug.out (vverb debugging) that whenever a
block is evicted from L1, a message is generated from the L2 component
(examples shown in the end of the post). I would like to ask what kind
of messages are these, since such evictions should only take place in
the L1 cache (as I have seen).
Thank you,
George
----------
Examples from debug.out
9751 <FastCacheImpl.cpp:308> {1000}- sys-L1d Evict:
MemoryMessage[Eviction (dirty)]: Addr:0xp:008947c00 Size:0 Serial: 5
Core: 0 DStream: true Outstanding Msgs: 0 Requires Ack
9752 <FastCMPCacheImpl.cpp:380> {1000}- sys-L2 Received on Port
RequestIn[0] Request: MemoryMessage[Eviction (dirty)]:
Addr:0xp:008947c00 Size:0 Serial: 5 Core: 0 DStream: true Outstanding
Msgs: 0 Requires Ack
9753 <FastCMPCacheImpl.cpp:547> {1000}- sys-L2 Received Eviction
(dirty) for 0xp:008947c00 from 0, state = OneSharer, sharers =
0000000000000000000000000000000000000000000000000000000000000001,
cache state = Invalid
12696 <FastCacheImpl.cpp:308> {1000}- sys-L1d Evict:
MemoryMessage[Eviction (writable)]: Addr:0xp:002c7bc00 Size:0 Serial:
5 Core: 0 DStream: true Outstanding Msgs: 0 Requires Ack
12697 <FastCMPCacheImpl.cpp:380> {1000}- sys-L2 Received on Port
RequestIn[0] Request: MemoryMessage[Eviction (writable)]:
Addr:0xp:002c7bc00 Size:0 Serial: 5 Core: 0 DStream: true Outstanding
Msgs: 0 Requires Ack
12698 <FastCMPCacheImpl.cpp:547> {1000}- sys-L2 Received Eviction
(writable) for 0xp:002c7bc00 from 0, state = OneSharer, sharers =
0000000000000000000000000000000000000000000000000000000000000001,
cache state = Exclusive
30456 <FastCacheImpl.cpp:308> {3000}- sys-L1i Evict:
MemoryMessage[Eviction (clean)]: Addr:0xp:009a7d9c0 Size:0 Serial: 7
Core: 0 DStream: false Outstanding Msgs: 0 Requires Ack
30457 <FastCMPCacheImpl.cpp:361> {3000}- Received on Port
FetchRequestIn[0] Request: MemoryMessage[Eviction (clean)]:
Addr:0xp:009a7d9c0 Size:0 Serial: 7 Core: 0 DStream: false Outstanding
Msgs: 0 Requires Ack
30458 <FastCMPCacheImpl.cpp:547> {3000}- sys-L2 Received Eviction
(clean) for 0xp:009a7d9c0 from 1, state = OneSharer, sharers =
0000000000000000000000000000000000000000000000000000000000000010,
cache state = Shared
