[gem5-users] How to port a reinforcement learning algorithm (maddpg) on top of gem5?
I'm trying to port maddpg on top of gem5 Here's my process: First I've downloaded the maddpg from open ai: https://github.com/openai/maddpg (I've also installed all the dependencies for maddpg on the multi-particle environment) In the next step, I used the following command to train the maddpg o top of gem5 for a simple policy. *Command: sudo ./build/X86/gem5.opt configs/example/se.py --cpu-type=DerivO3CPU --caches --mem-type=DDR4_2400_8x8 --mem-size=8GB --cmd=./train -options="--scenario simple"* When I tried executing this command, I encountered the following output: sudo ./build/X86/gem5.opt configs/example/se.py --cpu-type=DerivO3CPU --caches --mem-type=DDR4_2400_8x8 --mem-size=8GB --cmd=./train -options="--scenario simple"gem5 Simulator System. http://gem5.orggem5 is copyrighted software; use the --copyright option for details.gem5 version 21.0.0.0gem5 compiled Jun 15 2021 10:46:56gem5 started Jul 23 2021 00:43:08gem5 executing on osboxes, pid 7057command line: ./build/X86/gem5.opt configs/example/se.py --cpu-type=DerivO3CPU --caches --mem-type=DDR4_2400_8x8 --mem-size=8GB --cmd=./train '-options=--scenario simple'warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`warn: membus.master is deprecated. `master` is now called `mem_side_ports`warn: membus.master is deprecated. `master` is now called `mem_side_ports`warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`Global frequency set at 1 ticks per secondwarn: DRAM device capacity (16384 Mbytes) does not match the address range assigned (8192 Mbytes)0: system.remote_gdb: listening for remote gdb on port 7000** REAL SIMULATION **info: Entering event queue @ 0. Starting simulation...warn: ignoring syscall access(...)warn: ignoring syscall access(...)warn: ignoring syscall access(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall access(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall access(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall access(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall mprotect(...)warn: ignoring syscall set_robust_list(...)warn: ignoring syscall rt_sigaction(...) (further warnings will be suppressed)warn: ignoring syscall rt_sigprocmask(...) (further warnings will be suppressed)info: Increasing stack size by one page.info: Increasing stack size by one page.info: Increasing stack size by one page.info: Increasing stack size by one page.info: Increasing stack size by one page.info: Increasing stack size by one page.info: Increasing stack size by one page.info: Increasing stack size by one page.warn: MOVNTDQ: Ignoring non-temporal hint, modeling as cacheable!warn: ignoring syscall prctl(...)Exiting @ tick 346243000 because exiting with last active thread contextSimulated exit code not 0! Exit code is 1 I used the *pyinstaller* to convert the train.py file into a binary executable. Can someone explain to me the reason, why the training is not happening? or any suggestions to get the result? References: 1. gem5: https://www.gem5.org/documentation/general_docs/building 2. maddpg algorithm: https://github.com/openai/maddpg ___ 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: 4-core ARM with fs.py and fs_bigLITTLE.py
Hi Majid, Out of curiosity, are you sure the configuration is the same? Could you try to rebuild the bootloader in system/arm/bootloader/arm64 and make sure the config script is pointing to it? (Either with M5_PATH or by using the --bootloader option) Please let me know if this works Kind Regards Giacomo > -Original Message- > From: Majid Jalili via gem5-users > Sent: 21 July 2021 05:44 > To: gem5 users mailing list > Cc: Majid Jalili > Subject: [gem5-users] 4-core ARM with fs.py and fs_bigLITTLE.py > > Hi, > > I am using the following commands for the fs.py and fs_bigLITTLE.py: > > ./build/ARM/gem5.opt ./configs/example/fs.py --caches --mem-size=64GB - > -kernel /home/cc/disks/binaries/vmlinux.arm64 --disk > /home/cc/disks/disks/ubuntu-18.04-arm64-docker_big.img -n 4 --machine- > type VExpress_GEM5_V1 > > > > ./build/ARM/gem5.opt ./configs/example/arm/fs_bigLITTLE.py --caches -- > mem kernel /home/cc/disks/binaries/vmlinux.arm64 --disk > /home/cc/disks/disks/ubuntu-18.04-a > ig.img --machine-type VExpress_GEM5_V1 --big-cpus 4 --little-cpus 0 > > > When I run the lscpu command, I would see 1 CPU for fs.py and 4 CPUs for > the fs_bigLITTLE.py. > I was trying to figure out why the first script can bring only one CPU up, and > the other all 4 CPUs, but has no success. > I made sure all four CPUs are created in the config files. > > Thanks! > Majid 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
[gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache
Hi Gabriel Many thanks for your insight and input. I have taken on board your suggestion and simplified the customisation of CHI.py and CHI_config.py by just using the CHI_Config.CHI_RNF() class object and adding another method to CHI_Config.CHI_RNF(), called addSharedL2Cache. Also I have started testing with 1 cluster which contains 1 CPU and permutating with shared/private L2 cache. >> I would then suggest two non-tested options. You can assign the L2 >> controller to cpu.l2 after registering it as downstream_components of l1i >> and l1d. Let's hope it will set the desired name. Will try this out. Best regards J.Osmany -Original Message- From: Gabriel Busnot via gem5-users [mailto:gem5-users@gem5.org] Sent: 22 July 2021 08:40 To: gem5-users@gem5.org Cc: Gabriel Busnot Subject: [gem5-users] Re: CHI - Cluster CPUs having a shared L2 cache Hi Javed, Woops, I didn't see the split option in your first post. My bad. I think the l2 is actually named "system.cpu0.l1i.downstream_destinations" and you will find it in the ini file. I think this is due to the way gem5 sets SimObject names. When you assign a SimObject to several object attributes (cpu.l2, cpu.l1i and finally cpu.l1d), it will have one of the names according to the complex SimObject and SimObjectVector logic. for some reason, it does not end up as a child of cpu0.l1d despite it being the last in the list. I am regularly fighting SimObject naming logic as well, that's normal ;) Also check the warnings in the output. Some of them will warn you about SimObject reparenting. Sadly, SimObject name is determined by the attribute you set it to and you are not supposed to change it. I would then suggest two non-tested options. You can assign the L2 controller to cpu.l2 after registering it as downstream_components of l1i and l1d. Let's hope it will set the desired name. The other "last resort" option is to violate SimObject._name privacy and set it manually after the SimObject has been assigned for the last time... I would advise against that, though. Whenever possible, it is actually best to assign a SimObject at the time of object creation and never assign it again afterwards... Not always possible, though. Also make use of "private" attributes (i.e., attributes with a name starting with '_') as much as possible. It bypasses the SimObject assignment logic and solves many issues. Gabriel ___ 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: How to redirect the fopen to open a different file instead of specifed filename in the program binary given as input to gem5 simulator in SE mode
Hi Gogineni, If you REALLY CAN'T modify the app, I would then replace the file(s) your app opens with a symlink to the file you want to open. And if you feel in a hacky mood, you can dive in src/sim/syscall_emul.hh and hardcode path override in openatFunc. Needless to say this is a terrible long term solution, but a fun exercise to get in touch with syscall emulation ;) Gabriel ___ 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: CHI - Cluster CPUs having a shared L2 cache
Hi Javed, Woops, I didn't see the split option in your first post. My bad. I think the l2 is actually named "system.cpu0.l1i.downstream_destinations" and you will find it in the ini file. I think this is due to the way gem5 sets SimObject names. When you assign a SimObject to several object attributes (cpu.l2, cpu.l1i and finally cpu.l1d), it will have one of the names according to the complex SimObject and SimObjectVector logic. for some reason, it does not end up as a child of cpu0.l1d despite it being the last in the list. I am regularly fighting SimObject naming logic as well, that's normal ;) Also check the warnings in the output. Some of them will warn you about SimObject reparenting. Sadly, SimObject name is determined by the attribute you set it to and you are not supposed to change it. I would then suggest two non-tested options. You can assign the L2 controller to cpu.l2 after registering it as downstream_components of l1i and l1d. Let's hope it will set the desired name. The other "last resort" option is to violate SimObject._name privacy and set it manually after the SimObject has been assigned for the last time... I would advise against that, though. Whenever possible, it is actually best to assign a SimObject at the time of object creation and never assign it again afterwards... Not always possible, though. Also make use of "private" attributes (i.e., attributes with a name starting with '_') as much as possible. It bypasses the SimObject assignment logic and solves many issues. Gabriel ___ 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
