Indan Zupancic
Indan Zupancic
@kent-mcleod: Should I add your singed-off-by to commit e7322128697208c7 "smp: Don't check for IPIs in sel4_atomic_exchange", or should I squash it with the revert of commit 3d2ae69f9cb184c34b6b5, commit bb7b956f13 "Remove...
I thought the benchmarking code took the kernel entry timestamp after taking the kernel lock, so I'm curious how you measured a change there?
Well, `clh_lock_acquire` is inlined, and now it's smaller. If that causes the difference, then making it out-of-line may improve performance further. Otherwise the only other explanation I can think of...
No need for that, but it would be good to check that it's indeed code bloat that's the main cause and not something more subtle. A comparison with `clh_lock_acquire` out-of-line...
Thinking about it a bit more, 5-10% performance difference seems crazy. Are you sure it's not just noise?
> I still haven't had a chance to sit down and run these again sorry. Same here. > I could run sel4bench on specific hardware platforms and upload the logs...
The machine got restarted halfway the ODROID_XU4_debug_hyp_clang_32 test run, confusing the result parser. The tests itself passed. The TX2 machine maybe turned off currently.
After the update, SABRE_release_SMP_clang_32 hangs in MULTICORE0004, which does cross-core task cleanup.
> Feels a bit strange that we can assume time to be in sync over all cores, but if the hardware achieves that, no reason not to use it. Agreed....
I only tested the synchronisation test on aarch64. The diff I see is either 0 or 1 ticks.