I had a chance to look into this, and the problem is that the data structure storing the sequence of locked reads is shared across all thread contexts, which means that if a thread context A locks an address and then B locks a different address, A has to unlock its address first, before B can, even though A and B's address are not the same. I'm not sure why this problem doesn't show up until you hit 8 cores, but it is addressed by the patch series I linked to above; specifically by https://gem5-review.googlesource.com/c/public/gem5/+/8189, which creates a separate structure for each context. I'll work on getting this merged, but if you need a fix right now you can basically just copy the changes from locked_mem.cc and locked_mem.hh and fix this problem.
Also, it looks like the reason you aren't getting a proper mapping of several copies of the "hello, world" program onto the multiple cores is that you have each one's path in separate strings surrounded by quotes, which you then put semicolons in between. They all have to go in one string, so your --cmd argument for se.py with two cores should look like this: --cmd='tests/test-progs/hello/bin/riscv/linux/hello;tests/test-progs/hello/bin/riscv/linux/hello' <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Thu, Dec 6, 2018 at 4:21 AM Amir Lampel <[email protected]> wrote: > First of all, thanks for the help! > as I mentioned before, this is a starting point for me for linux,python > and gem5 combined so even the most trivial things might take me some time > to figure out, I know this isnt optimal for problem solving so I apologize > in advance. > > As for the command line I used, I tried to run it this way: > build/RISCV/gem5.opt configs/example/se2.py --num-cpus=2 > --cpu-type=TimingSimpleCPU --caches > --cmd='tests/test-progs/hello/bin/riscv/linux/hello';'tests/test-progs/hello/bin/riscv/linux/hello' > but it seems this line did not assign workloads to all the cpus correctly > as I was only getting one "hello world" output and can be confirmed by > looking at the stats.txt output file to see that cpu1 did not execute any > instructions. > > So until I get a better understanding of the optparse python module and > the Options.py script I made a little change in se.py to assign the > workloads the way I expected it to, basically instead of using the > "get_processes" method, I am using these line: > numThreads = 1 > multiprocesses=[Process(cmd = > 'tests/test-progs/hello/bin/riscv/linux/hello', pid = 100 + i) for i in > xrange(options.num_cpus)] > > and with this modified script, this is the command line im using: > build/RISCV/gem5.opt configs/example/se.py --num-cpus=8 > --cpu-type=TimingSimpleCPU --caches > > It seems this is where my problem is originating like Jason suspects since > I tried running a different binary on each core, using a simple test.c code > that I compiled using a risc-v cross compiler instead of using multiple > copies of the hello binary and it initially seems like that solved the > issue though I still did not test this completely. I will try to follow > Jason's suggestions to track down to problem and will keep you posted if I > find anything. > > Thanks, > Amir. > > > בתאריך יום ה׳, 6 בדצמ׳ 2018 ב-4:11 מאת Alec Roelke < > [email protected]>: > >> Would you mind posting the exact command you used to run se.py? I should >> have some time in the next couple of days to look into this. >> >> Also, you may want to try applying this patch series, which changes the >> behavior of LR/SC and the AMO instructions to work better: >> https://gem5-review.googlesource.com/c/public/gem5/+/8188/7. I think >> you'll only need that one and the three above it. I don't think they've >> been updated in a while, so they may not apply cleanly, but they may fix >> your problem. >> >> On Wed, Dec 5, 2018 at 10:39 AM Jason Lowe-Power <[email protected]> >> wrote: >> >>> Hi Amir, >>> >>> The warning is coming from here: >>> https://gem5.googlesource.com/public/gem5/+/master/src/arch/riscv/locked_mem.hh#118 >>> (BTW, it's always helpful to grep for the warning or panic in the code to >>> see what generates it.) >>> >>> I think this is a bug in RISC-V SE mode, but I'm not sure exactly what >>> the problem is. You're running multiple copies of the hello binary. I could >>> be that they are all using the same physical address for some reason >>> (though, this shouldn't be the case). I would try running with the Exec >>> flag to see what instruction is causing this problem (and stop running >>> after 186707000 ticks, too, so the log doesn't get too long). >>> >>> Let us know if you track down the issue. >>> >>> Cheers, >>> Jason >>> >>> On Tue, Dec 4, 2018 at 8:19 AM Amir Lampel <[email protected]> >>> wrote: >>> >>>> Hello everyone, >>>> >>>> I have already posted this question on stack overflow here: >>>> >>>> https://stackoverflow.com/questions/53591189/consecutive-sc-failures-on-gem5-simple-config-script >>>> and I'm following a suggestion I got there to send my issue here. >>>> >>>> I just started working with gem5 a few weeks ago and I tried to expand >>>> on the "two-level.py" and "simple.py" scripts found in the learning-gem5 >>>> book by Jason in a way that will add more cores to the system to make it a >>>> simple multi-core classic memory configuration with riscv cores. >>>> >>>> I am running into a problem when I run a se simulation where a looping >>>> warning message stating: >>>> "warn: 186707000: context 0: 10000 consecutive SC failures." is >>>> incremented by 10000 each iteration is preventing my simulation from >>>> running. I tried to search the web and the wiki site for an explanation on >>>> this warning but I could not find anything helpful. >>>> >>>> I tried looking in the default configuration script "se.py" to see how >>>> it is implemented there and I could not see what I am doing differently in >>>> my script (apart from being a very dumbed down version) moreover I noticed >>>> the same problem occurs when I raise the number of cpu's above 8 even when >>>> running with the default gem5 se.py configuration script. >>>> *note: all of the configuration scripts are running using the "hello >>>> world" binary >>>> >>>> What is causing this warning message and how do I avoid it? >>>> >>>> this is my code: >>>> https://pastebin.com/NgZXk1Py >>>> >>>> running using this command line: >>>> build/RISCV/gem5.opt configs/testing_configs/riscv_multicore.py >>>> >>>> Help will be appreciated. >>>> Thanks, >>>> Amir. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
