Re: [Gems-users] Fwd: L1 miss breakdown

[Mike Marty <mikem@xxxxxxxxxxx>]

If the Sender field in the ResponseMsg is insufficient (I don't recall if
the L2 changes this when sending data from memory to the L1), then just
add additional fields used for profiling.

--Mike


>   I thought about a similar thing, which was to do what you told in the
>   sequencer hitCallback (the hh_store_hit and h_load_hit in the end trigger
>   the call of this function). But at that point in the code I have no idea
>   where originally the requested data is satisfied. I can always try to ask
>   all L2 caches and the directory about their content but I guess this would
>   be misleading.  For example, as far as I understood,  if a request was
>   satisfied from the memory the data will be copied to the L2 cache which
>   requested the data and then t will be passed to the L1 cache. In this
>   backwards path I could not find any information propagating back to the L1
>   cache telling which component originally supplied the request. The network
>   messages that are being passed only give information about the component
>   which sends the message to it (e.g.  L2 cache after updating its data
>   (assume that this data actually was supplied by the mmemory) sends  a
>   message to the L1 cache and in this network message the sender seems as
>   L2 and, of course not the directory or memory.
>
>   So, that is what I found out looking into the code, but of course I may
>   be mistaken. Since my understanding was in this line I could not use the
>   strategy you mentioned. Maybe I'm still missing something. Is this the
>   case?
>
>      Thanks for your attention,
>
>         Derin Harmanci
>
>
>
> Quoting Mike Marty <mikem@xxxxxxxxxxx>:
>
> >
> > One technique I've used is to modify hh_store_hit and h_load_hit in the L1
> > controller to pass back which component (memory, local L2, remote L2, etc)
> > that satisfied the request.  Then profile this.
> >
> > --Mike
> >
> > >
> > >  Hello,
> > >
> > >    I sent this message earlieri but I'm resending it. I'm really missing
> > >   some point and need some help (some pointers maybe).
> > >
> > >        Derin Harmanci
> > >
> > >
> > >
> > > ----- Forwarded message from mehmetderin.harmanci@xxxxxxx -----
> > >     Date: Thu, 21 Sep 2006 15:21:25 +0200
> > >     From: mehmetderin.harmanci@xxxxxxx
> > > Reply-To: Gems Users <gems-users@xxxxxxxxxxx>
> > >  Subject: [Gems-users] L1 miss breakdown
> > >       To: Gems Users <gems-users@xxxxxxxxxxx>
> > >
> > >
> > >
> > >    Hello all,
> > >
> > >       I'm trying to understand the MSI_MOSI_CMP_directory protocol. My
> > main
> > >    objective is actually to have a breakdown of L1 misses, the breakdown
> > >    being local L2 hit, remote L2 hit and on-chip miss (off-chip hit).  I
> > >    assume all L2 misses correspond to on-chip misses, however to
> > distinguish
> > >    if an L2 hit is local or remote I need to figure out at what points
> > >    exactly an L2 hit occur. I took the following path but it did not help
> > >    me too much. I found out all the actions of L2 cache controller where
> > the
> > >    DataBlk is read from the L2 cache directly (as if the data was already
> > >    in the L2 cache and it was found in the cache). However there are about
> > >    ten of these functions and I'm a little bit lost in the protocol to
> > >    understand what they do exactly. Is there a way to filter out these
> > >    functions (i.e. to figure out which correspond to actual L2 hits)? Or
> > >    I should look transition by transition to figure out the actual hits?
> > >    Does anybody have an idea how to do the breakdown, if the above is too
> > >    complicated? I'll really appretiate any help, since I've been working
> > on
> > >    this for quite a time and I do not find a way yet.
> > >
> > >       Thanks,
> > >
> > >         Derin Harmanci.
> > > _______________________________________________
> > > 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.
> > >
> > >
> > > ----- End forwarded message -----
> > >
> > >
> > > _______________________________________________
> > > 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.
> > >
> > _______________________________________________
> > 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.
> >
> >
>
>
> _______________________________________________
> 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.
>