Also there is an Owner state implemented in the L2. If the Owner replaces
to memory, then yes, memory could end up responding even if another CMP is
Shared
--Mike
> For the first question, you can modify the protocol as your design, both of
> the L2 cache and the directory.
> For the second question, these buffer are not connected according to their
> name, but according to their "virtual_network" No. Buffers with the same No.
> are connected together.
>
>
> 2007/1/12, Lei Yang <lya755@xxxxxxxxxxxxxxxxxxxx>:
> >
> > I see. So with this protocol (MSI_MOSI_CMP_directory), if Processor 0 is
> > the
> > only sharer of one cache line, after it evicts this line, the directory
> > state is still S. I've verified this with a simple trace. It doesn't
> > matter
> > with the current protocol because even if a line is shared by other L2
> > caches, as long as it is not in M state, it's always fetched from main
> > memory. But for a protocol that supports clean cache-to-cache data
> > transfer, this may be a problem.
> >
> > Another question is, when reading the protocol sm files, I couldn't find
> > where/how the buffers are connected. For example, there is a buffer for L2
> > cache called L1RequestToL2Cache (a local L1 -> this L2 bank), but for L1
> > cache, the buffer requestFromL1Cache is supposed to be Local L1 -> this L2
> > bank. So with different names, how are they actually connected? I mean,
> > after L1 sends a request to L2 using the requestFromL1Cache buffer, how
> > does
> > L2 actually receive it?
> >
> > Thanks list, you've been super helpful!
> >
> > Lei
> >
> > ----- Original Message -----
> > From: "Mike Marty" <mikem@xxxxxxxxxxx>
> > To: "Lei Yang" <lya755@xxxxxxxxxxxxxxxxxxxx>
> > Cc: "'Gems Users'" <gems-users@xxxxxxxxxxx>
> > Sent: Thursday, January 11, 2007 9:41 AM
> > Subject: Re: [Gems-users] Invalidate directory entry
> >
> >
> > >> That's for M state, right? For S state, would any action be taken?
> > Thanks
> > >> a
> > >> lot for your time!
> > >>
> > >
> > > Yes, for S state the L2 silently replaces.
> > >
> > >
> >
> >
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding "site:
> > https://lists.cs.wisc.edu/archive/gems-users/" to your search.
> >
> >
>
|