subject:"\[gem5\-users\] Multiprogrammed simulation in x86 SE in O3CPU is broken"

Re: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

2020-02-13 Thread Abhishek Singh

Hi,
I will try my best to get the fix and share with the community. Also, if
you guys need help in testing the commit when submitted to review, please
let the community know. So however is interested can run tests and post the
result on online which is viewable by the maintainer and when important
features like multi core/multithreaded/multi programmed simulations and
others more have problem the developer can fix it so that previous
developers commit are not nullified
In this particular scenario someone did develop the environment for multi
core/multi threaded/multi programmed and now his/her effort needs to be
redone because we as community as whole did not pay attention when a commit
is submitted.
Currently in my free time I have personally started testing all the merged
commit in git review and test atleast the applications which is there in
gem5 directory.
And I have already submitted a Jira ticket. And in the mailing list I did
mention which gem5 commit is still supporting multi programmed simulations.
I will try to fix the problem and submit

On Thu, Feb 13, 2020 at 9:12 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi Abhishek,
>
> Let me first thank you for finding and reporting the problem.
> Since you are asking
>
>
> *"please also inform all the developers to not push commit if their commit
> disturbs the dependencies then try to fix them and after everything is
> fixed then only merge to public gem5!" *
>
> I'd like to take the opportunity to explain which is the gem5 contribution
> workflow.
>
> Every time we post a patch for review, before it gets merged we
> automatically run a set of tests to verify the patch isn't breaking anything
> .
> If one (or more) of the tests fails, it won't be possible to merge the
> patch.
> Please have a look at
>
> https://github.com/gem5/gem5/blob/master/TESTING.md
>
> to have an idea on how this works.
>
> So why things break?
>
> Gem5 has a lot of features that could be tested (SE mode, FS mode, Ruby
> mem, Classic mem, AtomicCPU, TimingCPU, MinorCPU, O3CPU, Checkpointing,
> FastForwarding, SMT, SMP ... just to mention few)
>
> We try to cover the most significant ones but the combination of all this
> parameters makes it IMPOSSIBLE to test EVERYTHING.
> What we can do though is to prioritize some tests over some others. Or, if
> the test is fairly simple, we can consider adding it to the regression list.
>
> If you find that a feature is broken, you can use JIRA (
> https://gem5.atlassian.net/jira/your-work) to raise a ticket.
> We try to address the problems in a reasonable amount of time. It usually
> helps if, rather than saying "things are broken", we actually get a link to
> the commit which breaks the feature you are interested on (you can easilly
> bisect until you find the culprit).
>
> This will make it very likely for the bug to get a quick fix; or, by being
> an open source project, we would be very happy to receive a contribution
> fix from you if you feel like handling it yourself. I would be happy to
> provide all the support needed so it is up to you.
>
> Once the issue has been solved we can discuss to add an SMT test to the
> list so that we are sure things won't break again.
>
> Kind Regards
>
> Giacomo
>
> 
> gem5/TESTING.md at master · gem5/gem5 · GitHub
> 
> With this method, you can only run a single suite at a time. If you want
> to run more than one uid, you must call ./main.py multiple times..
> Currently, you must specify --skip-build if you want to run a single suite
> or run in batch mode. Otherwise, you will build gem5 for all architectures.
> github.com
>
>
>
>
>
>
> --
> *From:* gem5-users  on behalf of Abhishek
> Singh 
> *Sent:* 11 February 2020 19:34
> *To:* gem5 users mailing list 
> *Subject:* [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is
> broken
>
> Hello Everyone,
>
> The latest commit *135595a* is unable to support multi-core
> (multi-programmed) simulation on x86 O3CPU. I am pasting the terminal
> output showing a simple hello world program. The older commits of gem5 do
> support such multi-core (multi-programmed) simulation.
> Please note if we do not use SMT and use the number of CPUs as 2 for 2
> core simulation, the simulation reaches a point and goes in a never-ending
> loop.
>
> These problems are due to cause of recent commits, *please also inform
> all the developers *to not push commit if their commit disturbs the
> dependencies then try to fix them and after everything is fixed then only
> merge to public gem5!
>
> *Using SMT:*
> /build/X86/gem5.opt configs/example/se.py -c
> 'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello'
> --caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB
> --l1d_assoc=8 --l1i_assoc=8 --l2_assoc=16 --cacheline_size=64
> --cpu-type=DerivO3CPU --mem-type=DDR4_2400_8x8

Re: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

2020-02-13 Thread Giacomo Travaglini

Hi Abhishek,

Let me first thank you for finding and reporting the problem.
Since you are asking

"please also inform all the developers to not push commit if their commit 
disturbs the dependencies then try to fix them and after everything is fixed 
then only merge to public gem5!"

I'd like to take the opportunity to explain which is the gem5 contribution 
workflow.

Every time we post a patch for review, before it gets merged we automatically 
run a set of tests to verify the patch isn't breaking anything.
If one (or more) of the tests fails, it won't be possible to merge the patch.
Please have a look at

https://github.com/gem5/gem5/blob/master/TESTING.md

to have an idea on how this works.

So why things break?

Gem5 has a lot of features that could be tested (SE mode, FS mode, Ruby mem, 
Classic mem, AtomicCPU, TimingCPU, MinorCPU, O3CPU, Checkpointing, 
FastForwarding, SMT, SMP ... just to mention few)

We try to cover the most significant ones but the combination of all this 
parameters makes it IMPOSSIBLE to test EVERYTHING.
What we can do though is to prioritize some tests over some others. Or, if the 
test is fairly simple, we can consider adding it to the regression list.

If you find that a feature is broken, you can use JIRA 
(https://gem5.atlassian.net/jira/your-work) to raise a ticket.
We try to address the problems in a reasonable amount of time. It usually helps 
if, rather than saying "things are broken", we actually get a link to the 
commit which breaks the feature you are interested on (you can easilly bisect 
until you find the culprit).

This will make it very likely for the bug to get a quick fix; or, by being an 
open source project, we would be very happy to receive a contribution fix from 
you if you feel like handling it yourself. I would be happy to provide all the 
support needed so it is up to you.

Once the issue has been solved we can discuss to add an SMT test to the list so 
that we are sure things won't break again.

Kind Regards

Giacomo

[https://avatars2.githubusercontent.com/u/1524926?s=400=4]
gem5/TESTING.md at master · gem5/gem5 · 
GitHub
With this method, you can only run a single suite at a time. If you want to run 
more than one uid, you must call ./main.py multiple times.. Currently, you must 
specify --skip-build if you want to run a single suite or run in batch mode. 
Otherwise, you will build gem5 for all architectures.
github.com







From: gem5-users  on behalf of Abhishek Singh 

Sent: 11 February 2020 19:34
To: gem5 users mailing list 
Subject: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

Hello Everyone,


The latest commit 135595a is unable to support multi-core (multi-programmed) 
simulation on x86 O3CPU. I am pasting the terminal output showing a simple 
hello world program. The older commits of gem5 do support such multi-core 
(multi-programmed) simulation.
Please note if we do not use SMT and use the number of CPUs as 2 for 2 core 
simulation, the simulation reaches a point and goes in a never-ending loop.

These problems are due to cause of recent commits, please also inform all the 
developers to not push commit if their commit disturbs the dependencies then 
try to fix them and after everything is fixed then only merge to public gem5!

Using SMT:
/build/X86/gem5.opt configs/example/se.py -c 
'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello'
 --caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB --l1d_assoc=8 
--l1i_assoc=8 --l2_assoc=16 --cacheline_size=64 --cpu-type=DerivO3CPU 
--mem-type=DDR4_2400_8x8 --mem-size=8GB --sys-clock=2.6GHz --cpu-clock=2.6GHz 
--smt

Global frequency set at 1 ticks per second
warn: DRAM device capacity (16384 Mbytes) does not match the address range 
assigned (8192 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7002
0: system.remote_gdb: listening for remote gdb on port 7003
panic: panic condition

Memory Usage: 8560136 KBytes
Program aborted at tick 0
— BEGIN LIBC BACKTRACE —
./build/X86/gem5.opt(_Z15print_backtracev+0x29)[0x55b3ff0e54e9]
./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x55b3ff0f7d9a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f379da2f890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f379b999e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f379b99b801]
./build/X86/gem5.opt(+0x59bd8f)[0x55b3fe8cdd8f]
./build/X86/gem5.opt(_ZN6X86ISA10Interrupts4initEv+0x110)[0x55b3feb80820]
./build/X86/gem5.opt(+0x15feaaa)[0x55b3ff930aaa]
./build/X86/gem5.opt(+0x6d960e)[0x55b3fea0b60e]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7a70)[0x7f379dceb010]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6364)[0x7f379dce9904]

[gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

2020-02-11 Thread Abhishek Singh

Hello Everyone,

The latest commit *135595a* is unable to support multi-core
(multi-programmed) simulation on x86 O3CPU. I am pasting the terminal
output showing a simple hello world program. The older commits of gem5 do
support such multi-core (multi-programmed) simulation.
Please note if we do not use SMT and use the number of CPUs as 2 for 2 core
simulation, the simulation reaches a point and goes in a never-ending loop.

These problems are due to cause of recent commits, *please also inform all
the developers *to not push commit if their commit disturbs the
dependencies then try to fix them and after everything is fixed then only
merge to public gem5!

*Using SMT:*
/build/X86/gem5.opt configs/example/se.py -c
'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello'
--caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB
--l1d_assoc=8 --l1i_assoc=8 --l2_assoc=16 --cacheline_size=64
--cpu-type=DerivO3CPU --mem-type=DDR4_2400_8x8 --mem-size=8GB
--sys-clock=2.6GHz --cpu-clock=2.6GHz --smt

Global frequency set at 1 ticks per second
warn: DRAM device capacity (16384 Mbytes) does not match the address range
assigned (8192 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7002
0: system.remote_gdb: listening for remote gdb on port 7003
panic: panic condition

Memory Usage: 8560136 KBytes
Program aborted at tick 0
— BEGIN LIBC BACKTRACE —
./build/X86/gem5.opt(_Z15print_backtracev+0x29)[0x55b3ff0e54e9]
./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x55b3ff0f7d9a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f379da2f890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f379b999e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f379b99b801]
./build/X86/gem5.opt(+0x59bd8f)[0x55b3fe8cdd8f]
./build/X86/gem5.opt(_ZN6X86ISA10Interrupts4initEv+0x110)[0x55b3feb80820]
./build/X86/gem5.opt(+0x15feaaa)[0x55b3ff930aaa]
./build/X86/gem5.opt(+0x6d960e)[0x55b3fea0b60e]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7a70)[0x7f379dceb010]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6364)[0x7f379dce9904]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6364)[0x7f379dce9904]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f379dce3409]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x68a5)[0x7f379dce9e45]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6364)[0x7f379dce9904]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f379de1bbf8]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f379dce3409]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyRun_StringFlags+0x76)[0x7f379dd936d6]
./build/X86/gem5.opt(_Z6m5MainiPPc+0x8f)[0x55b3ff0f66ff]
./build/X86/gem5.opt(main+0x38)[0x55b3fe864a68]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f379b97cb97]
./build/X86/gem5.opt(_start+0x2a)[0x55b3fe88c1aa]
— END LIBC BACKTRACE —
Aborted (core dumped)

*Using 2 CPUs*
./build/X86/gem5.opt configs/example/se.py -c
"tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello"
--caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB
--l1d_assoc=8 --l1i_assoc=8 --l2_assoc=16 --cacheline_size=64
--cpu-type=DerivO3CPU --mem-type=DDR4_2400_8x8 --mem-size=8GB
--sys-clock='2.6GHz' --cpu-clock='2.6GHz' -n 2
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Feb 11 2020 13:57:48
gem5 started Feb 11 2020 14:21:49
gem5 executing on comparchT640, pid 17942
command line: ./build/X86/gem5.opt configs/example/se.py -c
'tests/test-progs/hello/bin/x86/linux/hello;tests/test-progs/hello/bin/x86/linux/hello'
--caches --l2cache --l1d_size=32kB --l1i_size=32kB --l2_size=2MB
--l1d_assoc=8 --l1i_assoc=8 --l2_assoc=16 --cacheline_size=64
--cpu-type=DerivO3CPU --mem-type=DDR4_2400_8x8 --mem-size=8GB
--sys-clock=2.6GHz --cpu-clock=2.6GHz -n 2

Global frequency set at 1 ticks per second
warn: 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
0: system.remote_gdb: listening for remote gdb on port 7001

   -

   -

  -

 -

REAL SIMULATION 
info: Entering event queue @ 0. Starting simulation...
Hello world!
Hello world!

Best regards,

Abhishek
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Re: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

Re: [gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

[gem5-users] Multiprogrammed simulation in x86 SE in O3CPU is broken

3 matches

Site Navigation

Mail list logo

Footer information