No, I am not getting any error; so it is fine for me. I was doing some change and got to know this. I will ignore this. Thanks. Thanks and Regards Sparsh Mittal
On Mon, Oct 24, 2011 at 1:48 PM, avadh patel <[email protected]> wrote: > > > On Mon, Oct 24, 2011 at 11:40 AM, sparsh mittal > <[email protected]>wrote: > >> >> >>> 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. >> >> I forgot to mention that MMIO addresses are generally put above the RAM > space by kernel. So you'll see memory access beyond RAM size. What type of > error are you getting? Its fine if you do calculate the tag and set it in > cache. Also its access count is very small (4 in your results) so you can > ignore it. > > >> 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. >> >> I don't have any real numbers for Spec benchmarks :( > > - Avadh > > >> 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
