Hi Steve,
Thanks again for the information! I'll look into this.
Jiayuan
----- Original Message -----
From: "Steve Reinhardt" <[EMAIL PROTECTED]>
To: "M5 users mailing list" <m5-users@m5sim.org>
Sent: 2007年12月10日 7:19 AM
Subject: Re: [m5-users] help with broadcast/snoop handling
> It's hard to say exactly what the source of the problem is, but a few
> things are apparent:
>
> - You shouldn't be receiving responses from two different caches to a
> ReadExRequest no matter what is going on with MemInhibit. Only the
> owner cache should be responding, and there shouldn't be more than one
> owner at a given point in time.
>
> - The bus coherence is based on the wired-OR behavior of both
> MemInhibit and Shared lines (emulated by the corresponding flags in
> the packet struct), and as you've noted, when you start copying the
> packets to do the broadcast then those lines don't behave as global
> wired-ORs anymore. I'd be surprised if there are simple fixes for
> this. You will probably have to adjust the coherence protocol itself
> to deal with some of the consequences of not having these wired-OR
> signals. This is just a fact of life... coherence on a more general
> interconnect is harder than coherence on a bus, even when you have
> broadcasts.
>
> - There are some latent bugs in the new coherence protocol (even on a
> bus) if you have multiple L1s behind each of multiple L2s. To
> constrain the problem space, I'd just use a single level of caches
> while you're debugging your interconnect, then go to two levels of
> cache but just one L1 per L2, then if you need it try multiple L1s per
> L2.
>
> Steve
>
> On Dec 9, 2007 10:28 AM, jiayuan meng <[EMAIL PROTECTED]> wrote:
>>
>> FYI, just to be specific:
>>
>> if I find (mshr->hasTargets()==false), I assume this is a duplicated
>> response and discard it in Cache<TagStore>::handleResponse() . This
>> triggers the following error in the following ticks:
>>
>> m5.debug: build/ALPHA_SE/mem/cache/miss/mshr.cc:114: void
>> MSHR::TargetList::clearDownstreamPending(): Assertion
>> `mshr->downstreamPending' failed.
>>
>> back trace:
>>
>> #3 0x000000000063c502 in MSHR::TargetList::clearDownstreamPending
>> (this=0xe8ab20) at build/ALPHA_SE/mem/cache/miss/mshr.cc:114
>> #4 0x000000000063c7df in MSHR::markInService (this=0xe88798) at
>> build/ALPHA_SE/mem/cache/miss/mshr.cc:176
>> #5 0x000000000063dd05 in MSHRQueue::markInService (this=0xe86c28,
>> mshr=0xe88798)
>> at build/ALPHA_SE/mem/cache/miss/mshr_queue.cc:197
>> #6 0x00000000005c0dbd in BaseCache::markInServiceInternal (this=0xe86bf0,
>> mshr=0xe88798)
>> at build/ALPHA_SE/mem/cache/base_cache.hh:178
>> #7 0x00000000005c0e4b in Cache<LRU>::markInService (this=0xe86bf0,
>> mshr=0xe88798) at build/ALPHA_SE/mem/cache/cache_impl.hh:216
>> #8 0x00000000005d66a9 in Cache<LRU>::MemSidePort::sendPacket
>> (this=0xeda370) at build/ALPHA_SE/mem/cache/cache_impl.hh:1414
>> #9 0x00000000005d6d34 in Cache<LRU>::MemSidePort::processSendEvent
>> (this=0xeda370) at build/ALPHA_SE/mem/cache/cache_impl.hh:1453
>>
>> Thanks!
>>
>> Jiayuan
>>
>>
>>
>> ________________________________
>> From: [EMAIL PROTECTED]
>> To: m5-users@m5sim.org
>> Subject: RE: [m5-users] help with broadcast/snoop handling
>> Date: Sun, 9 Dec 2007 17:44:29 +0000
>>
>>
>>
>> I have another guess about how M5 manages duplicated responses:
>>
>> if a broadcast packet find a response in a snoop port, the pkt is tagged
>> "memInhibit" and responded to the upper level.
>> Because the pkt is a pointer, memInhibit will be seen by other ports, and
>> they will no longer respond to that packet.
>> As a result, there will be no duplicated response. Am I getting the point?
>>
>> Unfortunately, when modeling the traffic of the interconnection, I have to
>> duplicate the packets for broadcasting, and there is no guarantee that
>> packets will probe snoop ports before the dest ports (which was done in
>> bus::recvTiming). as a result, the memInhibit for one packet won't be seen
>> by its dulicates, and multiple responses may occur.
>>
>> In this case, I try to ignore and discard the duplicated packet in
>> Cache<TagStore>::handleResponse, but this results in other faults.
>>
>> Do you know any way out of this ?
>>
>> Thanks!
>>
>> Jiayuan
>>
>>
>> ________________________________
>> From: [EMAIL PROTECTED]
>> To: m5-users@m5sim.org
>> Date: Sun, 9 Dec 2007 14:28:43 +0800
>> Subject: [m5-users] help with broadcast/snoop handling
>>
>>
>> Hi all,
>>
>> I'm modeling the interconnection, when modeling the interconnection and
>> simulate all the routers, I am following the bus that broadcast a packet to
>> all the snoop ports if dest is broadcast.
>>
>> However, I came to this during debugging in timing mode with my
>> interconnection prototype:
>> m5.debug: build/ALPHA_SE/mem/cache/miss/mshr.hh:211: MSHR::Target*
>> MSHR::getTarget(): Assertion `hasTargets()' failed.
>>
>> triggered in Cache::handleResponse at the statement:
>> cache_impl.hh:707: MSHR::Target *initial_tgt = mshr->getTarget();
>>
>> doing a trace reveals that the broadcast request got two requests
>> (ReadExResp) from two nodes. (an L1 cache's memSidePort receives response
>> first from a peer L1's memSidePort, and then from the L2's memSidePort).
>>
>> Is there any clue on top of your head about how this happens? My guess is
>> the peer's L1 snoops the packet and found a match, so both the peer L1 and
>> L2 both responsed the request, the second request got missed in the mshr
>> because the target has already been fulfilled. What do you think?
>>
>> Thanks!
>>
>> Jiayuan
>> ________________________________
>> Share life as it happens with the new Windows Live. Share now!
>>
>>
>> ________________________________
>> Share life as it happens with the new Windows Live. Share now!
>> _______________________________________________
>> m5-users mailing list
>> m5-users@m5sim.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
> _______________________________________________
> m5-users mailing list
> m5-users@m5sim.org
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
