Thanks for the input Sam.
This code uses functions that I'm not familiar with yet, so I'll have to
take a good look at it later. Since I just need empty CPU caches after a
checkpoint restore, I started thinking about the state of the cache at that
point. There are no restrictions on the cache configuration when restoring
a checkpoint, so the memory system can be completely different than the one
used to create the checkpoint. There can be differences in the sizes of the
caches or even how many cache levels there are. I would assume that the
state of the cache can therefore not be restored to the state it was in
when the checkpoint was taken. So what state DOES the cache start in after
a restore? Does anyone know?
Sherif
Le lun. 29 mars 2021 à 21:02, Samuel Thomas <samuel_tho...@brown.edu> a
écrit :
> Hi Sherif and Arth,
>
> I had a similar problem. I resolved it by coming up with a somewhat hacky
> solution that utilizes the “forEachBlk” function call in the base tags. For
> context, I needed the main memory state to be consistent between a task
> running some component on both big and little CPU clusters in the ARM
> bigLITTLE configurations, so a lazy eviction protocol (such as invalidating
> cache blocks) wasn’t sufficient.
>
> In src/mem/cache/tags/base.cc, add the following public function.
>
> void
> BaseTags::flushAll(const char *parentName)
> {
> auto blk_flush = [&parentName](CacheBlk &blk) {
> Cache *parent = dynamic_cast<Cache*>(SimObject::find(parentName));
> if (blk.isValid() && blk.isDirty()) {
> parent->evictBlk(&blk);
> }
> };
> forEachBlk(blk_flush);
> }
>
> Then, in src/mem/cache.cc, you can add
>
> void
> Cache::flush()
> {
> tags->flushAll(name().c_str());
> }
>
> As you can tell, this is a very quick and dirty solution, so if there
> exists a better way to do this, I would also greatly appreciate and benefit
> from it!
>
> Best,
> Sam
>
> On Mar 29, 2021, at 12:46 PM, ARTHUR PERAIS via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Hi Sherif,
>
> Maybe the functionality is already there, but it may not be as easy as it
> sounds depending on what you mean by "flushing". Functionally invalidating
> cache lines is staightforward, but anything that is dirty in the cache
> should be written back, and this may be harder to handle especially if you
> want timing, not just functionality. If I had to start somewhere, I would
> see how back invalidations are handled (invalidation of L1 line because
> line is evicted from L2 and L2 is inclusive of L1) and apply the same
> process on dirty line sequentially.ur
>
> Maybe more context would be helpful :)
>
> Arth
>
> ------------------------------
> *De: *"gem5 users mailing list" <gem5-users@gem5.org>
> *À: *"gem5 users mailing list" <gem5-users@gem5.org>
> *Cc: *"Sherif AbdelFadil" <sherif.m.fa...@gmail.com>
> *Envoyé: *Lundi 29 Mars 2021 10:45:12
> *Objet: *[gem5-users] Flushing the Caches
>
> Hi,
> I was wondering if someone already implemented the functionality of
> flushing all caches in gem5. It seems relatively simple to implement and I
> imagine it would be useful in a lot of cases, yet I couldn't find anything
> online.
>
> Regards,
> Sherif
>
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
