patacongo commented on PR #9163: URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1533510456
> Thanks, I will do more test internally before I get the solid result, let me change this patch to draft. Ok. Whenever you are satisfied, I will be happy to merge. The condition that I would be most concerned about would be (1) round robin scheduling enabling, and (2) mixture of SCHED_FIFO and SCHED_RR threads. Isn't it true that any problems would occur on a context switch to a SCHED_FIFO thread where the timer is not restarted? And, if there are no other timing events, wouldn't it take a context switch back to a SCHED_RR thread to restarting time slice timer? While the SCHED_RR is running, there must be periodic timer events to enforce the time slice. If only SCHED_RR tasks are started, then the time slice event would always happen. We know that case works. If you want to keep the timer disabled, then you should not use SCHED_RR and you should not enable round robin scheduling*. If round robin scheduling is not enabled, then there would never be time slice events anyway and the timer should be stopped. That works too, right! [* SCHED_RR should not really be used in real time applications anyway because it results in non-deterministic behavior.] It is only the case where we switch between SCHED__RR and SCHED_FIFO threads that could be affected. This PR will case the internal timer to be restarted or not restarted. I doesn't actually disable the timer so I doubt that it would save any power on most timer peripherals. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
