fdcavalcanti commented on PR #16673: URL: https://github.com/apache/nuttx/pull/16673#issuecomment-3113140740
> I made some testing; executed some px4 based FC apps on MFPS with CONFIG_BUILD_KERNEL=y, CONFIG_SMP_NCPUS=4, CONFIG_DEBUG_ASSERTIONS=y, CONFIG_PRIORITY_INHERITANCE=y > > This is a very semaphore heavy data-driven app, with data producers (sensors) frequencies varying between 800Hz to 2KHz (several pipelines running in parallel), and also communication between kernel and userspace is based on semaphores (+ lots of context switches). > > With an earlier version of this PR (the SMP code is the same, just some cosmetic changes after that), the test has been succesfully running for 2 days 8 hours without errors: > > ``` > nsh> uptime > 15:25:05 up 2 days, 8:27 > ``` > > From the current PR version, I measured some CPU load with PX4 tools (px4 top): > > px4 top: > > ``` > PID COMMAND CPU(ms) CPU(%) USED/STACK PRIO(BASE) TSLICE FD > 0 CPU0 IDLE 77818 59.735 392/ 2048 0 ( 0) 0 5 > 1 CPU1 IDLE 75126 74.300 632/ 2016 0 ( 0) 0 5 > 2 CPU2 IDLE 104611 86.036 584/ 2016 0 ( 0) 0 5 > 3 CPU3 IDLE 111112 92.352 584/ 2016 0 ( 0) 0 5 > ... > Processes: 96 total, 5 running, 91 sleeping > CPU usage: 21.89% tasks, 0.00% sched, 78.11% idle > Uptime: 120.440s total, 77.818s idle > ``` > > With the current upstream version of the scheduling, the same tool gives me > > ``` > PID COMMAND CPU(ms) CPU(%) USED/STACK PRIO(BASE) TSLICE FD > 0 CPU0 IDLE 86933 61.260 408/ 2048 0 ( 0) 0 5 > 1 CPU1 IDLE 118468 73.182 616/ 2016 0 ( 0) 0 5 > 2 CPU2 IDLE 134880 81.970 584/ 2016 0 ( 0) 0 5 > 3 CPU3 IDLE 144453 91.641 584/ 2016 0 ( 0) 0 5 > ... > Processes: 96 total, 5 running, 91 sleeping > CPU usage: 22.62% tasks, 0.00% sched, 77.38% idle > Uptime: 458.290s total, 276.382s idle > ``` > > So initially it seems that the PR gives a small performance gain over the current version. > > Additionally, I used the px4 "perf" tool, which measures a bunch of latencies and latency deviations, also these show some smaller deviations in latencies with this PR (something to note here: the "sched" figure doesn't give anything reasonable on risc-v due to placement of sched note hooks; all the time is accounted in the thread's execution times). > > Also tested the rv-virt:smp64 target on qemu with ostest, which passes. Additionally I enabled CONFIG_PRIORITY_INHERITANCE and CONFIG_DEBUG_ASSERTIONS on the rv-virt:smp64 target and checked with ostest. > > And finally; I am not experiencing the original issue ... which we first tried to patch, but then requests to remove the whole pending lists etc. lead to this re-write. > > So all in all, I am currently quite happy with this... Seems the tests have different uptimes. Can you repeat with a similar run time? I'll test this on Espressif CI to so we have more answers on RISC-V and Xtensa. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
