On 5/22/19 7:43 PM, Jiri Gaisler wrote: > On 5/22/19 9:49 AM, Sebastian Huber wrote: >> On 22/05/2019 09:39, Jiri Gaisler wrote: >>> On 5/22/19 8:03 AM, Sebastian Huber wrote: >>>> Hello, >>>> >>>> in the libbsd there is a test for the Epoch Based Reclamation: >>>> >>>> https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c >>>> >>>> When I run this test using the leon3 BSP on real hardware (150MHz >>>> NGMP FP) the test completes successfully. >>>> >>>> If I run the test on the SIS, it is stuck at some point (using "-m >>>> 1" works): >>>> >>>> sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 2 >>>> build/sparc-rtems5-leon3-everything/epoch01.exe >>>> >>>> >>> This test needs a shorter time-slice in the simulator to succeed (-d >>> option). The more cpus, the lower number of clocks in the slice is >>> needed. Through trial-and-error, these values seem to work: >>> >>> 2 CPUs: -m 2 -d 25 >>> >>> 3 CPUs: -m 3 -d 10 >>> >>> 4 CPUs will not work, even if -d 1 is set. This is most likely a >>> simulator problem, I will try to find time to look at it in more >>> detail. A quick trace shows that all CPUs are stuck in a loop >>> checking for a lock or similar: >>> >> It seems cpu 2 and 3 are in _SMP_barrier_Wait(). The cpu 0 and 1 still >> to some stuff in the EBR algorithm (ck_* functions). Maybe the >> algorithm works only in case some random timing fluctuations occur. > Either that or there is a hidden race condition in the test that does > not show up on real hardware. I noticed that increasing the time slice > actually make the test succeed even on 4 cpus ..! > > -m 2 -d 200 PASS > > -m 3 -d 200 PASS > > -m 4 -d 200 FAIL > > -m 4 -d 400 PASS! > > BUT > > -m 3 -d 400 FAIL! > > I will try to add random delays to the interrupt response time to see if > that will make a difference. That is more inline with the real hardware ...
Adding a pseudo-random delay of 0 - 15 clocks to each trap/interrupt causes the test to pass on all cpu configurations with the default time slice (50)..! I am not sure what this means - it could be a hidden race condition, the algorithm might need some jitter to work or it could still be a simulator issue. Is there any chance that you could compile this test for sis-riscv? RISC-V has different atomic operations and trap handlers so it would be interesting to see if the test behaves differently. Jiri. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
