I don't know all (or any) of the details of MOESI_CMP_directory -- Dr.
Marty will probably weigh in on that shortly. But I do know it has an
enormous number of states and I would be mortally afraid of directly
manipulating them. I do know that a couple of protocols based on
MOESI_CMP_directory enter blocking states for some transient events --
and by blocking I do mean 'ignores/nacks all processor-side messages
until a non-transient or safe state is reached'.
As far as the membar is concerned, that will ensure the affected
processor isn't waiting for any coherence (actually, since Simics+Ruby
is SC, you don't need the membar at all), but it will not ensure that
the coherence state of the L1 is stable in the general case as it may be
affected by external coherence events. Again, I'm not sure if this can
actually happen in MOESI_CMP_directory itself, but I would suspect so.
Example: M->O downgrade.
The phantom requests I envisioned would be issued by a magic widget,
ruby-side, that would 'pretend' to be the processor whose L1 you wish to
'invalidate.' The end result wouldn't really be an 'invalidation' but it
would be the case that the cache would contain no data ever accessed by
the regular execution.
Regards,
Dan
Mladen Nikitovic wrote:
Dan Gibson wrote:
I have never personally tried calling these functions from outside the
protocol specification -- it might work, and it might not. It seems
like an approach that is worth trying, at least.
Right, I guess there's only one way to find out if it works or not.
Would be nice to verify that it actually works though...
As for worrisome states (besides M and O) -- there could be several
more because of transient states like MM, but this depends on the
protocol. Several protocols enter blocking states to avoid certain
directory races. You would have to wait for these transients to
resolve before you could force the writeback.
My idea is to execute the membar instruction before any flush of
cache. Would that force the transients to resolve? You mentioned that
protocols enter blocking states, but what states do you actually mean? I
can't recall any state called Blocking in the MOESI_CMP_directory
protocol so I guess you are referring to some transient states perhaps?
Here is another suggestion that might work: Since ruby uses true LRU
replacement, you could issue 'phantom' requests to the cache in such a
way that the associativity is saturated. For instance, if your
workload uses physical addresses 0 - 2^32-1, and your L1 is 4-way
associative, then four requests that map to the same set but have
addresses > 2^32-1 would effectively evict all the /real/ blocks from
the cache. Best of all, if each processor has its own 'phantom'
region, the coherence overhead would be minimal. On the other hand, if
your protocol is inclusive, this could lead to polluting the L2, and
you would have to lie to ruby when you specify g_MEMORY_SIZE_BYTES.
Thanks for the alternative approach, not sure who should perform the
"phantom" requests to the cache. Do you expect the processor being shut
down to make them?
I'm using the MOESI_CMP_directory protocol and I'm not sure whether it
is inclusive or not, do you know? Is there a parameter that dictates this?
Thanks for the answers so far.
Regards,
Mladen
Regards,
Dan
Mladen Nikitovic wrote:
I have found a possible solution:
I noticed that there is a section in the generated file
L1Cache_Transitions.C that handles L1Cache_Event_L1_Replacement and
L1Cache_Event_L1_Writeback events with the following actions:
i_allocateTBE(addr);
d_issuePUTX(addr);
x_copyDataFromL1CacheToTBE(addr);
ff_deallocateL1CacheBlock(addr);
return TransitionResult_Valid;
I have seen that these functions/methods (i_allocTBE etc) are
implemented in the L1Cache_Controller.C file, which means that I should
be able to call them via a L1cache_controller object, right?
This is what I propose:
go through the L1 cache block-by-block {
if I find a block that need to be written back I call the methods
(i_allocateTBE, d_issuePUTX, x_copyDataFromL1CacheToTBE, and
ff_deallocateL1CacheBlock) via the corresponding controller in the
L1Cache_Controller_vec vector.
}
If this is correct, I have a follow-up question since I'm not a
coherence protocol expert: My initial thought was to perform a writeback
only when I see a block that is in the M and O state, but I might have
missed any other vital states. Also, there are many intermediate states,
do I need to consider those possibilities also?
Regards,
Mladen
Mladen Nikitovic wrote:
The result I would like to achieve is the consequence from (temporarily)
disabling the power lines of the cache, which would mean that all data
would be lost. To avoid any inconsistency I need to invalidate all
entries and write back any data that is modified (or maybe also owner of
shared data?) before shutting down.
Couldn't the same processor that is being disabled do the necessary
actions just before the shutdown? If yes, then the question is how to
trigger the writebacks. My approach was to trigger the protocol actions
somehow, but I don't know how to actually do it nor do I know which
function does this.
Regards,
Mladen
Dan Gibson wrote:
You could 'force' another processor to issue stores to all the blocks
in the cache you need to invalidate. Of course, I'm not sure if this
would be applicable, since I don't know why you want the blocks
invalidated.
Mladen Nikitovic wrote:
Sorry, I forgot to actually specify my question :)
Since I don't belive the stxa instruction will fully generate the
desired events I wonder how I can achieve that in ruby. How can I
trigger the protocol to do the invalidation and possible writebacks for me?
Regards,
/Mladen
Mladen Nikitovic wrote:
Hi,
I would like to go through a cache and invalidate each entry
block-by-block. I would like to do it in a way such that necessary
events within ruby (replacements if needed) are triggered.
I found a code in opensolaris that is supposed to flush the cache (see
below) but I suppose that the instruction stxa will not trigger the
expected events in GEMS?
#define CH_CACHE_FLUSHALL(arg1, arg2, tmp1)
sub arg1,arg2,tmp1;
1:
stxa %g0, [tmp1]ASI_DC_TAG;
membar #sync;
cmp %g0, tmp1;
bne,pt %icc, 1b;
sub tmp1, arg2, tmp1;
I'm using the MOESI_CMP_directory protocol.
Thanks.
Regards,
Mladen
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx> <mailto: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 <mailto:Gems-users@xxxxxxxxxxx> <mailto: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.
--
http://www.cs.wisc.edu/~gibson <http://www.cs.wisc.edu/%7Egibson> <http://www.cs.wisc.edu/%7Egibson> [esc]:wq!
------------------------------------------------------------------------
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx <mailto: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 <mailto: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 <mailto: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.
--
http://www.cs.wisc.edu/~gibson <http://www.cs.wisc.edu/%7Egibson> [esc]:wq!
------------------------------------------------------------------------
_______________________________________________
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.
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}