You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by "xiaoxiang781216 (via GitHub)" <gi...@apache.org> on 2023/05/03 12:08:56 UTC
[GitHub] [nuttx] xiaoxiang781216 opened a new pull request, #9163: sched: Stop the sched timer when possible to save the power in tickless mode
xiaoxiang781216 opened a new pull request, #9163:
URL: https://github.com/apache/nuttx/pull/9163
## Summary
Remove KEEP_ALIVE_HACK to avoid waking up the device periodly. The workaround it's added by:
```
commit 6546fa39c7a292e919d1ea396d67bea8242f2c4b
Author: Gregory Nutt <gn...@nuttx.org>
Date: Tue Aug 12 11:12:00 2014 -0600
Tickless Stuff: Back out the risky timer operations when the ready-to-run
list is modified. That is unsafe. An ugly workaround is just to keep an
interval timer going all of the time with a minimum duration equal to the
timeslice interval.
```
But look like it doesn't needed anymore.
## Impact
tickless with round robin
## Testing
internal test
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] fjpanag commented on pull request #9163: sched: Stop the sched timer when possible to save the power in tickless mode
Posted by "fjpanag (via GitHub)" <gi...@apache.org>.
fjpanag commented on PR #9163:
URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1582178368
Issue #1733 can be linked.
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] xiaoxiang781216 commented on pull request #9163: sched: Stop the sched timer when possible to save the power in tickless mode
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on PR #9163:
URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1532918176
Since KEEP_ALIVE_HACK impact the device power consumption, it's better to remove this hack. From my understanding, the workaround is unnecessary, @patacongo could you confirm it?
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] xiaoxiang781216 commented on pull request #9163: sched: Stop the sched timer when possible to save the power in tickless mode
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on PR #9163:
URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1582202367
Done.
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] sched: Stop the sched timer when possible to save the power in tickless mode [nuttx]
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo merged PR #9163:
URL: https://github.com/apache/nuttx/pull/9163
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] xiaoxiang781216 commented on pull request #9163: sched: Stop the sched timer when possible to save the power in tickless mode
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on PR #9163:
URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1533069380
Thanks, I will do more test internally before I get the solid result, let me change this patch to draft.
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on pull request #9163: sched: Stop the sched timer when possible to save the power in tickless mode
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
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: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] sched: Stop the sched timer when possible to save the power in tickless mode [nuttx]
Posted by "xiaoxiang781216 (via GitHub)" <gi...@apache.org>.
xiaoxiang781216 commented on PR #9163:
URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1859131316
@patacongo this patch is testing internally for a long time, it's time to merge it.
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nuttx] patacongo commented on pull request #9163: sched: Stop the sched timer when possible to save the power in tickless mode
Posted by "patacongo (via GitHub)" <gi...@apache.org>.
patacongo commented on PR #9163:
URL: https://github.com/apache/nuttx/pull/9163#issuecomment-1533062730
> Since KEEP_ALIVE_HACK impact the device power consumption, it's better to remove this hack. From my understanding, the workaround is unnecessary, @patacongo could you confirm it?
I can't really confirm that the hack is still needed or not. If you test the code thoroughly and see no problems, then I will believe that the hack is no longer necessary.
That is because I never really understood the exact nature of the failure -- or maybe I just can't remember the exact failure. There are certain conditions in the OS where a major state change is in progress and during that state change, data structures are not in synchronization and the system is very fragile. I was seeing failures in this "fragile" state in tickless mode and this hack avoided the problem and kept the system healthy. I don't remember the exact details of the problem (that was 2014 -- nine years ago).
I would say that if thorough testing with the hack removed does not result in any failures does not reveal any problems, then the hack is no longer needed.
It does make me a little uncomfortable that I never understood (or at least can't remember) the exact cause of the problem but that if just went away, presumably from some other change(?)
--
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-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org