Hi Siro,
and thank you for all the help.
Yes, this also happens without Ruby (it was written further down in my
e-mail),
but I have tested few non-Ruby systems so far (so wasn't 100% sure).
I will try to apply this patch as soon as possible,
and will let you know of the results.
Best Regards,
Polydoros
On 11/20/19 5:09 PM, Ciro Santilli wrote:
Hi Polydoros,
There is a pending SVE O3 fix at:
https://gem5-review.googlesource.com/c/public/gem5/+/19173 could you try
with that fix to see if it works?
I believe that the fix is not Ruby specific, but maybe the problem only
happens in Ruby by coincidence.
We need to make some improvements to the patch before merging, but it
could already help.
On 11/18/19 6:00 PM, Polydoros Petrakis wrote:
Hi all,
I would like to report the following two findings in regard to ARM SVE +
Ruby + FS/SE:
A) When trying to run C STREAM benchmark v5.10
(https://www.cs.virginia.edu/stream/FTP/Code/stream.c), compiled for ARM
SVE,
I get the following assert error:
*gem5.opt: build/ARM/mem/packet.hh:1093: T* Packet::getPtr() [with T =
unsigned char]: Assertion `!isMaskedWrite()' failed.*
I have tried with both gcc/armclang:
a) aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
8.2-2019.01 (arm-rel-8.28)) 8.2.1 20180802
e.g.: aarch64-linux-gnu-gcc -Ofast --static
*-march=armv8.2-a+sve*-DNTIMES=5 -DSTREAM_ARRAY_SIZE=200000
-I../gem5/include/ -I../gem5/include/gem5 stream.c -L./ -o
sve_stream.exe -lm5
b) armclang (arm-hpc-compiler/19.3)
Stream runs OK, in the following 3 cases:
a) build without SVE flags
b) When I comment out the assert(But this could lead to errors ?)
c) Without Ruby/NoC (But we are currently interested in Ruby-NoC Systems).
The complete output is the following:
command line: ./build/ARM/gem5.opt --outdir=m5out/batch502_0001
configs/example/se.py --cpu-type=DerivO3CPU --caches --num-cpus=4
--num-dirs=4 --l2cache --mem-type=DDR4_2400_8x8 --num-l2caches=4
--mem-size=2GB --ruby --topology=Mesh_XY --mesh-rows=2
--network=garnet2.0 -c sve_stream.exe
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
warn: DRAM device capacity (16384 Mbytes) does not match the address
range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7004
0: system.remote_gdb: listening for remote gdb on port 7005
0: system.remote_gdb: listening for remote gdb on port 7006
0: system.remote_gdb: listening for remote gdb on port 7007
**** REAL SIMULATION ****
info: Entering event queue @ 0. Starting simulation...
warn: Replacement policy updates recently became the responsibility of
SLICC state machines. Make sure to setMRU() near callbacks in .sm files!
info: Increasing stack size by one page.
gem5.opt: build/ARM/mem/packet.hh:1093: T* Packet::getPtr() [with T =
unsigned char]: Assertion `!isMaskedWrite()' failed.
Program aborted at tick 24589000
--- BEGIN LIBC BACKTRACE ---
./build/ARM/gem5.opt(_Z15print_backtracev+0x19)[0x55976cece499]
./build/ARM/gem5.opt(_Z12abortHandleri+0x3d)[0x55976cee013d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f12b2d18730]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f12b1b0a7bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f12b1af5535]
/lib/x86_64-linux-gnu/libc.so.6(+0x2240f)[0x7f12b1af540f]
/lib/x86_64-linux-gnu/libc.so.6(+0x30102)[0x7f12b1b03102]
./build/ARM/gem5.opt(_ZN9Sequencer12issueRequestEP6Packet15RubyRequestType+0x5e9)[0x55976c2c2119]
./build/ARM/gem5.opt(_ZN9Sequencer11makeRequestEP6Packet+0x203)[0x55976c2c2513]
./build/ARM/gem5.opt(_ZN8RubyPort12MemSlavePort13recvTimingReqEP6Packet+0x37f)[0x55976c2b299f]
./build/ARM/gem5.opt(_ZN7LSQUnitI9O3CPUImplE13trySendPacketEbP6Packet+0xd8)[0x55976d3e0c58]
./build/ARM/gem5.opt(_ZN3LSQI9O3CPUImplE16SplitDataRequest17sendPacketToCacheEv+0x6c)[0x55976d3d7f3c]
./build/ARM/gem5.opt(_ZN7LSQUnitI9O3CPUImplE15writebackStoresEv+0x862)[0x55976d3e7992]
./build/ARM/gem5.opt(_ZN3LSQI9O3CPUImplE15writebackStoresEv+0x84)[0x55976d3de564]
./build/ARM/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE4tickEv+0x144)[0x55976d3ca994]
./build/ARM/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x137)[0x55976d39f0b7]
./build/ARM/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd9)[0x55976ced62e9]
./build/ARM/gem5.opt(_Z9doSimLoopP10EventQueue+0x77)[0x55976cef6157]
./build/ARM/gem5.opt(_Z8simulatem+0xccd)[0x55976cef718d]
./build/ARM/gem5.opt(+0x1e399ca)[0x55976cfdd9ca]
./build/ARM/gem5.opt(+0xcbd5f1)[0x55976be615f1]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x60f2)[0x7f12b2e720a2]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x62e9)[0x7f12b2e72299]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x62e9)[0x7f12b2e72299]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x62e9)[0x7f12b2e72299]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f12b2e6be69]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6992)[0x7f12b2e72942]
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x732)[0x7f12b2e6b852]
--- END LIBC BACKTRACE ---
Aborted (core dumped)
B) Additionally, when I disable the previous assert and run:
FS with multi-threaded SVE-Stream + OpenMP + DerivO3CPU + 2x2 Mesh +
garnet2.0 + MOESI_hammer/MOESI_CMP_directory + (4 cpu / 4 dirs / 4
L2-caches),
I observe:
a) Atomicity (+ OpenMP ) seems problematic?
The following code (from stream.c) prints garbage values:
/ pragma omp atomic//
// k++;//
// printf ("Number of Threads counted = %i\n",k);/
b) STREAM Benchmark finishes, but results contain errors,
when*OMP_NUM_THREADS > 1*.
I guess (a) could explain (b). The results get verified for some array
sizes (e.g.: 200,000), for 1/2/4 threads.
When running multi-threaded***OpenMP**STREAM without SVE*, all results
get verified (e.g.: array sizes = [43690, 252134, 243431, 151690,
200000] for 1/2/4 threads), although problem (a) persists.
STREAM + SVE (+ OpenMP) finish with errors, even with Classic Memory
System (without Ruby). I could do more runs to verify this, if needed.
I would like to ask about the current status of atomicity in Ruby, as
well as atomicity in regard to SVE.
( I have seen the relative status matrix in
http://www.gem5.org/Status_Matrix, but maybe it is outdated? )
Any information or help to resolve these issues is welcome.
Thanks in advance,
Polydoros Petrakis
-------
Institute of Computer Science (ICS),
Foundation for Research & Technology - Hellas (FORTH),
Heraklion, Crete, Greece.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
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-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
