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 < 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 <davide.basilio.bartol...@huawei.com> > *Sent:* 08 October 2020 10:40 > *To:* gem5 users mailing list <gem5-users@gem5.org> > *Cc:* Giacomo Travaglini <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 <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, > > > > This is annoying indeed. The main problem IMHO is that you shouldn’t be > using Options.py in the first place (this is why I am not personally using > swiss army knife scripts like fs.py). > > I suggest you to have a look at fs_bigLITTLE.py and use that as a > reference for a main/top level python config. > > > > Having said that, this is actually a real problem for people still using > fs.py-like scripts. Unfortunately removing default values from Options.py > will likely break some legacy scripts for some users, so I don’t feel > comfortable on doing it myself. It would be nice if at a certain point we > would take the brave decision of removing the script. > > > > Kind Regards > > > > Giacomo > > > > *From:* Davide Basilio Bartolini via gem5-users <gem5-users@gem5.org> > *Sent:* 08 October 2020 08:02 > *To:* gem5 users mailing list <gem5-users@gem5.org> > *Cc:* Davide Basilio Bartolini <davide.basilio.bartol...@huawei.com> > *Subject:* [gem5-users] CPU configuration and default values > > > > Hi gem5 users, > > > > I am working with my team to set up a CPU model and I am having some > trouble making sense of how the core settings are handled. > > > > The core configurations (for example, o3_arm_v7a.py [1]) allow (require?) > specifying parameters for the various components (for example, size, > associativity, etc. for the caches). > > I would expect those values to be used as defaults when using that core > model unless anything else is specified on the command line. > > > > However, it seems that those values are always overridden with the default > values for the command line parameters specified in Options.py [2] (for > example, l2_size has a default value of 16MB, which will be used > irrespective of what is defined in the configuration of the core). > > > > The consequence of this behavior is that I basically have to either remove > the default values from Options.py or pass a long command-line > configuration that reproduces exactly the default values I already specify > in the core configuration. > > That seems rather inefficient to me. > > Is there a better way to handle those default parameters? > > If not, it would seem sensible to me to remove the default values from > Options.py, so that defaults for the chose CPU type can be used. > > > > Thanks for any replies :-) > > > > -- dbb > > > > [1] > https://github.com/gem5/gem5/blob/stable/configs/common/cores/arm/O3_ARM_v7a.py > > [2] https://github.com/gem5/gem5/blob/stable/configs/common/Options.py > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >
_______________________________________________ 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
