[gem5-users] Re: How I can notify the NVMAIN model when I use “m5 resetstats” so that the NVMAIN model can also reset the stats in its model
Hi Liyichao, you can register a callback with the Stats::registerResetCallback function in base/statistics.hh. Gabe On Mon, Oct 12, 2020 at 7:15 PM Liyichao via gem5-users wrote: > Hi All: > > > > > >When I use gem5 + O3 based on armv8 with NVMAIN ddr4 model, I want > to know *how I can notify the NVMAIN model when I use “m5 resetstats”* so > that the NVMAIN model can also reset the stats in its model, e.g. > bandwidth, latency, because I will first run warmup for a few instrutions, > when warmup finished I reset stats in GEM5, and then go on running the > simulation parts. > > > > > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] How I can notify the NVMAIN model when I use “m5 resetstats” so that the NVMAIN model can also reset the stats in its model
Hi All: When I use gem5 + O3 based on armv8 with NVMAIN ddr4 model, I want to know how I can notify the NVMAIN model when I use “m5 resetstats” so that the NVMAIN model can also reset the stats in its model, e.g. bandwidth, latency, because I will first run warmup for a few instrutions, when warmup finished I reset stats in GEM5, and then go on running the simulation parts. ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: Invalid RubyRequestType
Hi Jason, Yes, I already tried this but I get the error “Invalid method call: Type ‘sequencer’ does not have a method evictionCallback” Στάλθηκε από το iPhone μου > 12 Οκτ 2020, 20:10, ο χρήστης «Jason Lowe-Power » έγραψε: > > > Hi Teo, > > That error is because you're still using MESI_Two_Level. You need to > recompile gem5 to use a different protocol. > > I.e., to use MESI_Two_Level you could do the following: > > scons build/X86_MESI_Two_Level/gem5.opt > > build/X86_MESI_Two_Level/gem5.opt > > To use MOESI_hammer you could do the following: > > scons build/X86_MOESI_hammer/gem5.opt --default=X86 PROTOCOL=MOESI_hammer > > build/X86_MOESI_hammer/gem5.opt > > In the second case, the parameters to scons mean the following: > - `--default=X86`: Use the file build_opts/X86 to get the default parameters > for the build > - `PROTOCOL=MOESI_hammer`: Override the "PROTOCOL" variable with MOESI_hammer > > Hopefully this helps! > > Cheers, > Jason > > >> On Sun, Oct 11, 2020 at 12:28 PM Θοδωρής Τροχάτος via gem5-users >> wrote: >> Hi all! I am new to the gem5 community and I am currently reproducing >> various things from InvisiSpec paper... >> >> I was wondering, how can I generate checkpoints in X86_MESI_Two_Level (I am >> using ruby memory model in my simulations) ? >> I know that checkpoints in Ruby can only be generated in MOESI_hammer, but I >> can't generate checkpoints with MOESI_hammer, either. >> I always get the error "panic: Runtime Error at >> MESI_Two_Level-L1cache.sm:279: Invalid RubyRequestType." >> >> Any ideas? >> >> Thanks in advance, >> Teo. >> >> -- >> - >> Τροχάτος Θεόδωρος >> Σχολή Ηλεκτρολόγων Μηχανικών & Μηχανικών Υπολογιστών >> Εθνικό Μετσόβιο Πολυτεχνείο >> - >> ___ >> gem5-users mailing list -- gem5-users@gem5.org >> To unsubscribe send an email to gem5-users-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: CPU configuration and default values
Hi Jason, Thanks for the pointers. So, as I understand it now, the "public" API for gem5 is the Python API and users are expected to write their own scripts against that API. That's what I am doing now, but still the issue with the default values surfaces back again. For example, in CacheConfig.py, size values for the caches are taken from the options (which then need to have some value) and there is no fallback to the values defined in the core configuration in case no option is passed [1]. So, then, back to my original question: why do we have default values in the core configurations [2] if then there is no way to use them? Or should CacheConfig also be considered just an example? Thanks again. -- dbb [1] https://github.com/gem5/gem5/blob/stable/configs/common/CacheConfig.py#L101 [2] https://github.com/gem5/gem5/blob/stable/configs/common/cores/arm/O3_ARM_v7a.py#L197 From: Jason Lowe-Power Sent: Thursday, October 8, 2020 5:25:18 PM To: Giacomo Travaglini Cc: Davide Basilio Bartolini; gem5 users mailing list; Bobby Bruce Subject: Re: CPU configuration and default values Hi Davide, I echo 100% of what Giacomo said. Also, there's a proposal for updating the Python API here: https://gem5.atlassian.net/browse/GEM5-432. That proposal is a pretty extreme example, and we'll probably end up with something closer to the status quo. You can also check out Learning gem5 to understand more about how to write config scripts from scratch: https://www.gem5.org/documentation/learning_gem5/part1/simple_config/. Finally, if you're interested in x86 FS scripts, there are some examples in gem5 resources (e.g., https://gem5.googlesource.com/public/gem5-resources/+/refs/heads/stable/src/parsec/configs/system/). Cheers, Jason On Thu, Oct 8, 2020 at 3:04 AM Giacomo Travaglini mailto:giacomo.travagl...@arm.com>> wrote: Davide, You are 100% right in your distinction between example platforms (forkable) and generic scripts; and that no-one should ever fork from fs.py; and that such script, if we still want to maintain it, shouldn’t be in the example directory. The “simple example script to replicate to match your use case” is the de-facto accepted philosophy among most gem5 developers (nowadays). The idea is to empower a user/researcher to easily adjust a python config to model a specific hardware topology. Some people in Arm got that in mind when they added the configs/example/arm subdir: https://github.com/gem5/gem5/tree/stable/configs/example/arm About investing some of your own time on cleaning up the configs: that would be great and I feel most maintainers are already sharing your views on what needs to be changed. If you are afraid of not having your patch accepted on upstream, a solution could be for you to post a RFC using JIRA (https://gem5.atlassian.net/secure/BrowseProjects.jspa) where you could describe what will be restructured and how. You will get a feedback from the rest of the community and you could make the decision whether it’s worth investing some of your time. Kind Regards Giacomo From: Davide Basilio Bartolini mailto:davide.basilio.bartol...@huawei.com>> Sent: 08 October 2020 10:40 To: gem5 users mailing list mailto:gem5-users@gem5.org>> Cc: Giacomo Travaglini mailto:giacomo.travagl...@arm.com>> Subject: Re: CPU configuration and default values Hi Giacomo, Thanks for your reply, I'll take a closer look at fs_bigLITTLE.py. I guess the question here for the gem5 maintainers is whether gem5 users are expected to hack their own simulation script even for "simple" cases or if there should be default scripts that don't have this kind of idiosyncrasies with default parameters (and possibly other legacy). Probably, the current answer is "yes", given that se.py and fs.py are in an "examples" directory. That doesn't seem ideal to me though: generic scripts to parse parameters and run simulations look like "standard" infrastructure to me that the simulator should probably provide, rather than examples that users are expected to fork and hack on (except for specific / advanced case). I guess the question there is whether the community wants to go in that direction or not. If yes, then thinking about promoting those "examples" to a more stable status and refactoring legacy issues along the way might be a good thing to think about. I (or others) could spend some time working on that, but it really only makes sense if there is a chance that the patch will be eventually accepted upstream, otherwise it's just simpler to have our own scripts on the side (as most people probably do already). Thanks. -- dbb From: Giacomo Travaglini via gem5-users mailto:gem5-users@gem5.org>> Sent: Thursday, October 8, 2020 11:17:43 AM To: gem5 users mailing list Cc: Davide Basilio Bartolini; Giacomo Travaglini Subject: [gem5-users] Re: CPU configuration and default values Hi Davide,
[gem5-users] Re: Invalid RubyRequestType
Hi Teo, That error is because you're still using MESI_Two_Level. You need to recompile gem5 to use a different protocol. I.e., to use MESI_Two_Level you could do the following: > scons build/X86_MESI_Two_Level/gem5.opt > build/X86_MESI_Two_Level/gem5.opt To use MOESI_hammer you could do the following: > scons build/X86_MOESI_hammer/gem5.opt --default=X86 PROTOCOL=MOESI_hammer > build/X86_MOESI_hammer/gem5.opt In the second case, the parameters to scons mean the following: - `--default=X86`: Use the file build_opts/X86 to get the default parameters for the build - `PROTOCOL=MOESI_hammer`: Override the "PROTOCOL" variable with MOESI_hammer Hopefully this helps! Cheers, Jason On Sun, Oct 11, 2020 at 12:28 PM Θοδωρής Τροχάτος via gem5-users < gem5-users@gem5.org> wrote: > Hi all! I am new to the gem5 community and I am currently reproducing > various things from InvisiSpec paper... > > I was wondering, how can I generate checkpoints in X86_MESI_Two_Level (I > am using ruby memory model in my simulations) ? > I know that checkpoints in Ruby can only be generated in MOESI_hammer, but > I can't generate checkpoints with MOESI_hammer, either. > I always get the error *"panic: Runtime Error at > MESI_Two_Level-L1cache.sm:279: Invalid RubyRequestType."* > > Any ideas? > > Thanks in advance, > Teo. > > -- > - > *Τροχάτος Θεόδωρος* > *Σχολή Ηλεκτρολόγων Μηχανικών & Μηχανικών Υπολογιστών* > *Εθνικό Μετσόβιο Πολυτεχνείο* > - > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
