Re: [Gems-users] save-caches/load-caches bug

[Byn Choi <bynchoi1@xxxxxxxxxxxx>]

My apologies, I misread your comment. Yes, the scheme (_only_) works  
if you have only one core per chip. But if you read carefully, I  
assumed a single-chip multicore environment in my original post. As I  
mentioned, the issue is precisely that the save-caches distinguishes  
the exiting lines at the chip-granularity, not at the core  
granularity. As soon as you have more than one core per chip  
(g_PROCS_PER_CHIP > 1 with CMP or SCMP protocols), you have a problem.  
To reiterate, after load-caches, all the cores but the first one of  
every chip remain completely empty.
Byn

On Mar 12, 2010, at 5:56 AM, Javi Merino wrote:

> Byn Choi wrote:
> > If you do CacheMemory::print() before save-caches and also do another
> > print() after load-caches, you will see that they are substantially
> > different. Specifically, with single-chip multicore chips, you'll see
> > that only core 0 has any lines allocated while all other cores (core
> > 1, 2, and 3 in a quad-core setup) are completely empty.
> >
> > You can also see this by ungzipping the cache checkpoints. With  
> > single-
> > chip multicore system, all the entries will say that they belong to
> > core 0. What this means is that, when you do load-caches, all the
> > transactions will only be fed into core 0.
> When I use the setup explained (do the save-caches with
> MOESI_SMP_directory, do the load-caches with whatever CMP protocol)  
> that
> doesn't happen.
>
> And yes, unzipping the cache checkpoints shows accesses for all the
> processors.
>
> > Byn
> >
> > On Mar 12, 2010, at 3:48 AM, Javi Merino wrote:
> >
> > > Byn Choi wrote:
> > > > Hello,
> > > >
> > > > I think I may have found a bug in the save-caches/load-caches
> > > > mechanism.
> > > >
> > > > Here, I'm assuming a single-chip multicore environment.
> > > >
> > > > [...]
> > > >
> > > > CacheMemory::recordCacheContents() has the line
> > > > tr.addRecord(m_chip_ptr->getID(), m_cache[i][j].m_Address, Address
> > > > (0), ... );
> > > > m_chip_ptr->getID() is the same for all the cores in the chip, i.e.
> > > > with single-chip multicore, this value is always 0.
> > > >
> > > > [...]
> > > >
> > > > Am I missing something here? Is there an option that should be  
> > > > set to
> > > > correct this behavior?
> > > Hi Bin, at my university, we do the warmup part of the checkpoint  
> > > with
> > > the MOESI_SMP_directory protocol and g_PROCS_PER_CHIP set to 1.
> > > Afterwards, we load the caches of single-chip multicores without
> > > problems: the data goes to the caches of the different cores.
> > >
> > > I think this is the correct way of doing it. Even if they are
> > > different
> > > coherence protocols, the data in the cache should be mostly the
> > > same, if
> > > your cache configurations are similar in size. After all, it is the
> > > most
> > > recently used data.
> > >
> > > That's my experience, but I'd like to know how do others in the list
> > > do
> > > the save-caches part of the workload creation.
> > >
> > > Regards,
> > > Javi
> > > _______________________________________________
> > > 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.