Re: [Gems-users] L1 misses in MOESI_CMP_directory

[Mike Marty <mikem@xxxxxxxxxxx>]

Yoav,

You point out a real issue.  The Ruby sequencer will issue something to 
the L1 controller whenever a state change is required.  For the L1 miss 
stats that the sequencer keeps track of, this is considered a miss even 
if it only changes state from E to M.  If you don't want these 
aberrations, then I suggest adding your own profile code to the L1 
controller.
--Mike


Yoav Etsion wrote:
> That is exactly the question I ran into when I started coding.
>
> My conclusion is that in this case, an L1 miss should be defined as a 'non-hit',
> which leads us to another question - what is a hit? two possible definitions:
> 1.
> A hit is an access occurring when cache contains valid data, such that
> any core request
> can be served without requesting fresh data from an external entity -
> another L1, L2,
> directory - but at a possible need for a permissions upgrade.
> This is a simple definition since hits/misses only depend on the state
> of the block and are
> not access dependent. In addition, insertions and eviction can be
> defined as transitions
> to/from states containing a valid block.
>
> 2.
> A combination of State/Event that allow the cache to respond immediately
> without having to turn to an external entity.
> This definition is more complex as it depends on the access type, therefore
> a valid cached block may produce either a hit or a miss, depending on
> the access.
> This makes insertions/evictions harder to define as well.
>
> The realization that this is basically an arbitrary choice lead me to
> go with the simpler
> definition, basically using a subset of all states as 'hit' states,
> such that any transition
> that involves a state outside this subset is considered a miss
> (the 'hit' states are S, O, M, M_W, MM, MM_W, SM, OM).
>
> But since you guys are the experts, I'd really appreciate your input
> on that matter :-)
>
> Thanks,
>
> Yoav
>
>
> On Nov 19, 2007 2:43 AM, Dave Z. <zhu_dave@xxxxxxxxx> wrote:
>   
> > Hi,
> >
> >
> > The profileMiss actions are commented out in MOESI_CMP_directory-L1cache.sm. If we try to profile the L1 misses, the assertion in profile_miss - RubySlicc_Profiler_interface.C fails. What would be a good way to profile L1 misses in CMP protocols?
> >
> >
> > Thanks,
> >
> >
> > Dave
> >
> >
> >
> >       ____________________________________________________________________________________
> > Be a better sports nut!  Let your teams follow you
> > with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
> > _______________________________________________
> > 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.
>