On 12/11/18 4:01 PM, Sebastian Huber wrote: > On 11/12/2018 15:55, Jiri Gaisler wrote: >>> Even if the screen is a guide of what to expect in some cases. >>> >>> How does the smp support in sis switch back and forth between the >>> cores? Per cycle, instruction, etc. Qemu switches per instruction >>> translation block as I recall. >> The scheduling slice is (dynamically) configurable in number of clock >> cycles. I currently have it set to 50 but the smp tests works also at >> 1000. The scheduling overhead is ~ 10% at 50 cycles, so the slowdown is >> acceptable even for non-smp loads. My plan is to simulate each cpu >> instance in a separate host thread, and synchronize them on events in >> the event queue. Not quite sure how well that will work though ...:-) > > How do you synchronize the simulated memory accesses across the threads?
For regular LD/ST instructions, reading and writing memory is atomic (single host instruction) so no particular synchronization is needed. For SPARC atomic instructions (CASA, SWAP, LDST) and peripheral access (APB bus), I plan to use mutexes around the memory access function call. This might fail if RTEMS uses standard ST instructions to write to semaphores instead of CASA etc. Having mutexes on all memory access will probably be too slow ... > > The big advantage of SIS compared to Qemu for example is that the > simulated execution is very predictable and stable across different > simulation runs. It would be nice if this would be also the case for > the SMP support even if this costs performance. So for example just > use a single thread and switch to an other processor every X > instructions. This is how it works now, and will be maintained. An extra option will be provided to allow use of threads. My goal is to have almost the same accuracy with threads as without. The threads will only deviate from each other at most x clocks (e.g. 50), and synchronize on each event in the event queue. For debugging, single-thread simulation should be used, while regression testing could be done with multi-threading. The current SMP tests are fairly short, so multi-threading is not really necessary at this point though... _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
