I really appreciate you for providing precise informations. Thank you. On Fri, May 8, 2009 at 2:22 PM, nathan binkert <[email protected]> wrote:
> Not currently. It would be a fair amount of work to add this capability. > > Nate > > On Fri, May 8, 2009 at 2:00 PM, Devraj Chapagain <[email protected]> > wrote: > > hi Korey, > > Thank you very much for your great response. > > Now, i have changed my configuration and have assigned block_size of 64 > for > > all caches (L1, L2 and L3). I changed some other files too and run scons > > after that i don't have block_size problem. > > Is there any possibilities of using different values for block_size of > > caches, like L1(16), L2(32) and L3(64)? If not, it's OK. Otherwise, > please > > inform me the way how we can use it. > > > > Thanks, > > dev. > > > > > > > > On Mon, May 4, 2009 at 9:13 AM, Korey Sewell <[email protected]> wrote: > >> > >> I havent really been following this thread *too closely* but it seems > >> like if you want to explain the problem in detail you need to answer > >> *at minimum* these questions: > >> 1) What benchmarks are your running? > >> 2) How many simulations are you running? > >> 3) What is the exact # of cores, CPU Model, cache size, cache ways, > >> block size, etc. for EACH simulation that you are running. Please list > >> them. A good way might be: > >> - Simulation 1: BENCHMARK=EON, CPU_MODEL=TimingSimpleCPU, 1 core, 1 > >> thread per core, 1 MB L1 Cache, Block Size = 64 > >> - Simulation 2: BENCHMARK=EON/GZIP, CPU_MODEL=O3CPU, 1 core, 2 > >> threads per core, 1 MB L1 Cache, Block Size = 64 > >> -etc. > >> 4) What is the error message you receive for each simulation. > >> > >> It sounds like you're having a problem running a SMT O3CPU simulation > >> on whatever benchmark. But even if that were the problem, you would > >> need to provide the above information so that someone could > >> *replicate* the error your getting and suggest a way to solve it. > >> > >> On Mon, May 4, 2009 at 12:04 PM, Devraj Chapagain < > [email protected]> > >> wrote: > >> > I am extremely sorry for confusing you. > >> > > >> > I am using the same cache architecture for different simulations. It > >> > works > >> > for some simulations and gives problem to some others. In precise, It > >> > works > >> > for single thread per core simulations but gives problem with multi > >> > thread > >> > per core. (Note! I have used same block size for all the caches). > >> > > >> > The error message is: > >> > > >> > > ............................................................................................................. > >> > warn: Increasing stack size by one page. > >> > m5.opt: build/ALPHA_SE/mem/cache/cache_impl.hh:312: bool > >> > Cache<TagStore>::access(Packet*, typename TagStore::BlkType*&, int&, > >> > PacketList&) [with TagStore = LRU]: Assertion `blkSize == > >> > pkt->getSize()' > >> > failed. > >> > Program aborted at cycle 2903472000 > >> > > >> > > ............................................................................................................. > >> > Could you please suggest me any thing possible reasons to this > problem. > >> > > >> > Thanks, > >> > devraj > >> > > >> > On Sun, May 3, 2009 at 2:15 PM, nathan binkert <[email protected]> > wrote: > >> >> > >> >> > Sorry, I think i can't make you clear. > >> >> No, you are not being very clear at all. Be precise. What *exactly* > >> >> are you changing? > >> >> > >> >> > When i used the same block_size ( 64) for all caches (L1, L2 and > >> >> > L3), i > >> >> > got > >> >> > results. But when i changed the configuration, i.e., change the > size > >> >> > of > >> >> > L1, > >> >> > L2 and L3, i got "Assertion `blkSize == pkt->getSize()' failed" > >> >> > problem > >> >> > on > >> >> > all the simulations (even for the simulations which gave the output > >> >> > previously with same block_size). > >> >> This isn't clear. What did you change? Just the size of the cache? > >> >> Nothing about the block size? Are you changing the block size at all > >> >> in the ones that are failing? What are you changing in the runs that > >> >> are failing? > >> >> > >> >> > My question is: What will be the reason for getting this assertion > >> >> > problem > >> >> > when number of threads goes increasing evenif the same architecture > >> >> > is > >> >> > working for single threads? > >> >> > > >> >> > Could you please provide me some suggestions so that i could run > all > >> >> > the > >> >> > simulations successfully. > >> >> You have to give a better bug report if you want help. Before you > >> >> sent us your configuration and all we saw was that you were changing > >> >> the block size so that it was not all the same for all caches. THIS > >> >> IS NOT ALLOWED. Other than that, we have no clue what exactly you're > >> >> doing. > >> >> > >> >> I'm sorry, but we're getting very frustrated at your lack of a > >> >> detailed bug report. Read this article about giving bug reports > >> >> before you try again: > >> >> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html > >> >> > >> >> Also, read the m5 page on reporting problems: > >> >> http://www.m5sim.org/wiki/index.php/Reporting_Problems > >> >> > >> >> > >> >> Nate > >> >> _______________________________________________ > >> >> m5-users mailing list > >> >> [email protected] > >> >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >> > > >> > > >> > _______________________________________________ > >> > m5-users mailing list > >> > [email protected] > >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >> > > >> > >> > >> > >> -- > >> =========== > >> Korey L Sewell > >> PhD Candidate > >> Computer Science & Engineering > >> University of Michigan > >> _______________________________________________ > >> m5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
