The key question is: what input to the benchmark are you using, and how much memory does it take on a real machine? The most likely explanation is that the input you're using actually needs 20+ GB of memory, so with gem5 overheads, hitting 30GB is not unreasonable.
That may not be the case, but it's the first thing you need to rule out before claiming that it's a problem with gem5. Steve On Fri, Apr 27, 2012 at 12:20 AM, Mahmood Naderan <[email protected]>wrote: > Hi Korey, > I ran with valgrind and attached the outputs. As you can see from tick > 300000000, it starts eating memroy until it get killed. There is no > progress though. > > There are some message before that tick number however I don't think > they are the root of this problem. > > Thanks, > -- > // Naderan *Mahmood; > > On 4/27/12, Korey Sewell <[email protected]> wrote: > > From my experience, if something is going to quickly eat 30GB of memory > > then that raises some red flags: > > 1) What is the expected memory footprint for your workload? Can you check > > that from the benchmark's publication? If 30GB isnt close to the expected > > footprint then it's a simulator problem, else you need to shorten the > input > > set for your benchmark. > > > > 2) If this is SE mode and not FS mode this especially makes me think this > > is a memory leak and you are not deallocating blocks correctly somewhere. > > Run your program using 'valgrind', turn "leak-check" on and you can check > > this scenario. (30GB in FS mode is still quite high though...) > > > > > > > > > > On Thu, Apr 26, 2012 at 12:56 PM, Mahmood Naderan > > <[email protected]>wrote: > > > >> Are using x86? > >> I modified as yours, however in the middle of simulation, both of them > >> eat all the memory (they quickly reach 30GB of memory). > >> I don't know are they correctly reading the input or not. > >> > >> On 4/26/12, Ankita (Garg) Goel <[email protected]> wrote: > >> > Hi Mahmood, > >> > > >> > The following has worked for me for gromacs and leslie3D: > >> > > >> > #435.gromacs > >> > gromacs = LiveProcess() > >> > gromacs.executable = binary_dir+'435.gromacs/exe/gromacs_base.gem5' > >> > data=data_dir+'435.gromacs/data/ref/input/gromacs.tpr' > >> > gromacs.cmd = [gromacs.executable] + > >> ['-silent','-deffnm',data,'-nice','0'] > >> > > >> > #437.leslie3d > >> > leslie3d=LiveProcess() > >> > leslie3d.executable = > binary_dir+'437.leslie3d/exe/leslie3d_base.gem5' > >> > stdin=data_dir+'437.leslie3d/data/test/input/leslie3d.in' > >> > leslie3d.cmd = [leslie3d.executable] > >> > leslie3d.input=stdin > >> > leslie3d.output='leslie3d.stdout' > >> > > >> > I think these are the same as mentioned on the wiki, not sure though. > >> Hope > >> > that helps! > >> > > >> > Regards, > >> > Ankita > >> > > >> > On Thu, Apr 26, 2012 at 9:18 AM, Mahmood Naderan > >> > <[email protected]>wrote: > >> > > >> >> Hi, > >> >> It seems that X86 SE mode has problems running some of spec > benchmarks > >> >> which use '<' for input reading. Examples are gamess, leslie3d, tonto > >> >> and gromacs. > >> >> > >> >> Has anyone successfully run them? Please let me know. > >> >> -- > >> >> // Naderan *Mahmood; > >> >> _______________________________________________ > >> >> gem5-users mailing list > >> >> [email protected] > >> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> >> > >> > > >> > > >> > > >> > -- > >> > Regards, > >> > Ankita > >> > Graduate Student > >> > Department of Computer Science > >> > University of Texas at Austin > >> > > >> > >> > >> -- > >> -- > >> // Naderan *Mahmood; > >> _______________________________________________ > >> gem5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > >> > > > > > > > > -- > > - Korey > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
