> > On Mon, Oct 24, 2011 at 8:05 AM, sparsh mittal <[email protected]>wrote: > >> Hello >> >> See my code and output generated: >> Purpose: To see the range of addresses passed to L2 cache. >> Code1: First, In logic.h, AssociativeArray, probe function, I added: >> >> V* probe(int coreID, T addr) >> { >> float addrInGB = (float)addr/(float)(1024*1024*1024); >> if (isL2) >> { >> * count_address_range*(addr); >> if(addrInGB > 4.5) >> std::cout<<" coreID = "<<coreID<<" addr = "<<addr<<" addr in GB >> "<<addrInGB<<"GB "<<"\n"; >> } >> ..... >> } >> ===================== >> Code2: >> int range_[10]; >> void *count_address_range*(W64 addr) >> { >> // int range[10]; >> float addGB = (float)addr /(float) (1024*1024*1024); >> >> if(addGB < 0.5) >> range_[0]++ ; >> else if (addGB<1.0) >> range_[1]++; >> else if (addGB<1.5) >> range_[2]++; >> else if (addGB<2) >> range_[3]++; >> else if (addGB<2.5) >> range_[4]++; >> else if (addGB<3.0) >> range_[5]++; >> else if (addGB<3.5) >> range_[6]++; >> else if (addGB<4.0) >> range_[7]++; >> else if (addGB<4.5) >> range_[8]++; >> else >> range_[9]++; >> } >> =============== >> At the end of simulation, I printed the range_[] variable. >> Now I ran it. Here is the output for -stopinsns 100000000. >> ======================================== >> Simulator is now waiting for a 'run' command. >> >> coreID = 0 addr = 18446744073709551615 addr in GB 1.71799e+10GB >> coreID = 1 addr = 18446744073709551615 addr in GB 1.71799e+10GB >> coreID = 3 addr = 18446744073709551615 addr in GB 1.71799e+10GB >> coreID = 2 addr = 18446744073709551615 addr in GB 1.71799e+10GB >> >> >> index 0 6256 >> index 1 8890 >> index 2 0 >> index 3 0 >> index 4 0 >> index 5 0 >> index 6 0 >> index 7 0 >> index 8 2034 >> index 9 4 >> ================================ >> >> 1. How about this strange address which is e+10 GB? >> > > I think the reason might be because of MMIO is still processed via regular > memory hierarchy access. To simulate some delay in MMIO currently we simply > let it pass through the cache subsystem as we dont store data in caches it > doesn't affect IO correctness. To fix this, we need to add a MMIO interface > to BaseMachine class and allow users to configure MMIO access delay via > config files. > > I could not understand what you wrote; but for my work, I am only concerned with the fact: 1. This large address should not create an error, either in cache 2. Is it OK to calculate its tag and set by the regular method? If both these answers are positive, that's fine for me.
2. I have observed that the addresses are either <1GB or >4GB. I have not >> seen any address in-between 1&4GB. Strange! >> > > Does your benchmark/kernel application have huge memory footprint? Have you > tested your benchmark in real machine to see how many pages does it access? > > Actually, this was a simple run without running any benchmark, by using: (qemu) simconfig -run -stopinsns 10000000 -kill-after-run. ===================================== I just ran the simulation with four-core, spec06 benchmarks. See the output: coreID = 0 addr = 18446744073709551615 addr in GB 1.71799e+10GB coreID = 2 addr = 18446744073709551615 addr in GB 1.71799e+10GB coreID = 3 addr = 18446744073709551615 addr in GB 1.71799e+10GB coreID = 1 addr = 18446744073709551615 addr in GB 1.71799e+10GB Stopped after 2919566 cycles, 10000000 instructions and 43 seconds of sim time (cycle/sec: 67896 Hz, insns/sec: 232558, insns/cyc: 3.4251666172300950) index 0 2845 index 1 459 index 2 0 index 3 0 index 4 38336 index 5 0 index 6 13088 index 7 0 index 8 88605 index 9 4 Much Better distribution! I will run spec06 benchmarks with ref input. If you know that they have any memory footprint consideration, (esp. when used with Marss) let me know. Thanks a lot for your time. - Avadh > > Sparsh >> >> On Mon, Oct 24, 2011 at 1:47 AM, DRAM Ninjas <[email protected]>wrote: >> >>> I believe this is the result of how QEMU allocates simulated physical >>> memory. It puts a hole between 3.5GB and 4.0GB and moves the missing 500MB >>> above 4.0GB in order to accomodate memory mapped IO (or else something that >>> I don't understand) into that hole. >>> >>> In other words, for a 4GB memory system, the usable space would be >>> 0-3.5GB and 4.0GB-4.5GB. I believe what we do in DRAMSim is just to subtract >>> off the hole to properly map the request to the proper place. >>> >>> On Sun, Oct 23, 2011 at 4:54 PM, sparsh mittal >>> <[email protected]>wrote: >>> >>>> Hello >>>> Here is the result of printing in logic.h, the class is >>>> AssociativeArray: >>>> V* probe(T addr) >>>> { >>>> float addrInGB = (float)addr/(float)(1024*1024*1024); >>>> if (isL2 ) >>>> { >>>> >>>> std::cout<<" addr = "<<addr<<" addr in GB "<<addrInGB<<"GB >>>> "<<"\n"; >>>> } >>>> >>>> ..... >>>> } >>>> >>>> I have added isL2 variable, to print the addresses for only L2 cache. >>>> >>>> addr = 16785400 addr in GB 0.0156326GB >>>> * addr = 4808179704 addr in GB 4.47797GB >>>> ............ >>>> addr = 4808179704 addr in GB 4.47797GB* >>>> addr = 16793584 addr in GB 0.0156402GB >>>> ... >>>> addr = 4808177792 addr in GB 4.47796GB >>>> addr = 51168 addr in GB 4.76539e-05GB >>>> addr = 16804352 addr in GB 0.0156503GB >>>> addr = 16902064 addr in GB 0.0157413GB >>>> >>>> addr = 16902088 addr in GB 0.0157413GB >>>> addr = 4824080080 addr in GB 4.49277GB >>>> >>>> I did -m 4G. I am compiling with c=4. >>>> I am surprised, that the addr goes more than 4GB, although I have never >>>> seen any error of 'address out of bounds'. >>>> >>>> Do you know how it is possible? >>>> >>>> >>>> Thanks and Regards >>>> Sparsh Mittal >>>> >>>> _______________________________________________ >>>> http://www.marss86.org >>>> Marss86-Devel mailing list >>>> [email protected] >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>> >>>> >>> >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
